Modelo de contexto para un KPI de capacidad industrial

Un KPI de capacidad puede parecer autosuficiente: una cifra, una fecha y un color. En una reunión de dirección, sin embargo, la misma cifra puede significar una familia concreta, toda una línea, una ventana de turno o una agregación mensual. Si no se conserva el contexto, dos personas pueden leer el valor de forma razonable y llegar a decisiones incompatibles.

El modelo de contexto es la ficha que acompaña al KPI. No crea un cálculo nuevo ni decide qué tablero debe usar la empresa. Su función es dejar claro qué entidad se observó, en qué ventana, bajo qué estado, con qué unidad y desde qué fuente. El modelo también registra lo que todavía no está demostrado, para que una ausencia de información no se convierta en una conclusión.

Para interpretar un KPI de capacidad hay que registrar, como mínimo, la entidad, la familia, la ventana, el estado, la unidad y la fuente. OPC UA define conceptos de información y comunicación para intercambiar datos industriales, pero la selección de esas dimensiones debe comprobarse en los registros locales y en la pregunta que se quiere responder.

Qué problema resuelve el contexto

Un valor agregado pierde significado cuando se separan el numerador, el denominador y las condiciones que los produjeron. “Capacidad 82” puede ser unidades por hora, lotes por turno o porcentaje de una capacidad teórica. Incluso si la unidad está escrita, falta saber si el equipo estaba disponible, en cambio de formato, en mantenimiento o esperando material.

El contexto no intenta describir toda la arquitectura. Solo recoge las dimensiones necesarias para que el lector pueda repetir la lectura. Una ficha demasiado extensa se vuelve difícil de mantener; una ficha mínima pero incompleta oculta decisiones importantes. La frontera práctica consiste en registrar lo que cambia la interpretación del KPI y dejar explícito lo que queda fuera.

Tampoco es un catálogo semántico ni una lista de propietarios. El significado de una métrica y quién puede aprobarla son decisiones relacionadas, pero distintas. Esta página se concentra en las dimensiones y la fuente que hacen legible el valor. La responsabilidad de cada dato debe aparecer en el procedimiento local, no en una inferencia del artículo.

Las dimensiones que no conviene mezclar

Entidad y recurso

Empiece por el objeto que el KPI representa. Puede ser una línea, una célula, una máquina, una familia de equipos o una planta. Escriba el identificador nativo y el nombre que aparece en el informe. Un alias visible ayuda al lector, pero no debe reemplazar la clave con la que se recupera el registro original.

La entidad también necesita una relación con el nivel de agregación. “Planta” no equivale a “línea 3”, y “línea 3” no equivale a “estación de inspección”. Si la consulta combina niveles, indique la regla de agrupación. Cuando esa regla no exista o cambie entre periodos, marque el KPI como no comparable hasta documentarla.

Familia o mezcla de producto

La familia describe qué tipos de producto están incluidos. Dos órdenes en la misma línea pueden tener ciclos, formatos o controles de calidad distintos. Si el KPI no separa la familia, no lo presentes como capacidad de una referencia concreta. Es válido usar “todas las familias” como valor, siempre que la consulta y el periodo lo respalden.

No invente una familia a partir del nombre comercial. Use el campo de producto, lote u orden que la fuente autoritativa defina. Si hay una tabla de equivalencias, registre su versión y la fecha en que fue aplicada. Un cambio de catálogo puede modificar la agrupación aunque el dato operativo no haya cambiado.

Ventana temporal

La ventana responde a cuándo se observa el KPI. Registre inicio, fin, zona horaria, calendario y si los extremos son inclusivos. Un turno que cruza medianoche requiere una fecha operativa además de la fecha civil. Para comparaciones, conserve también la regla que alinea ventanas de distinta duración.

La fecha de consulta no es la fecha del dato. Guarde ambas y, cuando exista, la fecha de recepción. Un informe consultado el día siguiente puede incorporar correcciones o retrasos que no estaban disponibles al cierre del turno. Si la fuente actualiza retroactivamente una medida, anote la versión o el momento de extracción.

Estado operativo

El estado indica en qué condición se encontraba el recurso o la orden cuando se registró la medida. “Disponible”, “produciendo”, “parada planificada” y “cambio de formato” no deben tratarse como sinónimos. Si el sistema solo conserva un estado resumido, registre el campo original y la pérdida de detalle.

El estado no prueba la causa. Que una estación aparezca como “espera” no demuestra que el material faltara; puede ser un código usado para varias situaciones. El contexto debe conservar el valor observado y, si procede, una nota de interpretación separada. La causa exige otra evidencia y otra autoridad.

Medida y unidad

Escriba el nombre del indicador, su unidad y el sentido de la medida. Un contador, una duración y una tasa pueden compartir el nombre “capacidad” en informes distintos. Incluya el factor de conversión si se presenta una unidad derivada y conserve la unidad de origen.

El denominador merece la misma atención que el numerador. Unidades por hora de calendario no equivale a unidades por hora disponible. Si el denominador se filtra por estado, turno o familia, la ficha debe decirlo. No rellene un denominador ausente con la capacidad nominal de la máquina.

Fuente y procedencia

La fuente identifica dónde nació el dato y qué consulta lo transformó. Puede ser un historiador, un registro MES, una orden ERP o un fichero autorizado. Guarde la ruta lógica, la versión de la consulta y la fecha de extracción. Si el valor fue agregado fuera del sistema de origen, conserve el cálculo o la referencia a su repositorio.

Los estándares de interoperabilidad ayudan a nombrar intercambios, pero no sustituyen la procedencia. ISA describe niveles y objetos para relacionar control, operaciones y negocio; usar ese marco para preguntar dónde vive el dato no permite afirmar que una instalación concreta cumpla la norma.

OPC UA especifica modelos de información, mensajes, comunicación y conformidad para interoperabilidad; no prueba la calidad ni la latencia de una instalación local. La especificación oficial delimita ese alcance, por lo que el modelo debe añadir la comprobación de la planta.

La ficha mínima de contexto

Una ficha útil debe poder leerse sin abrir cinco sistemas. La siguiente estructura sirve como punto de partida, no como contrato universal:

Campo	Qué anotar	Pregunta de control
Entidad	Identificador nativo, alias y nivel	¿Qué equipo o planta representa?
Familia	Código, catálogo y versión	¿Qué productos quedan dentro o fuera?
Ventana	Inicio, fin, zona y calendario	¿Qué periodo se midió realmente?
Estado	Valor original y traducción local	¿En qué condición estaba el recurso?
Medida	Nombre, numerador y denominador	¿Qué significa la cifra?
Unidad	Unidad de origen y conversiones	¿Se puede repetir el cálculo?
Fuente	Sistema, consulta, versión y fecha	¿Dónde se verifica el valor?
Pendientes	Campos ausentes y responsable de comprobarlos	¿Qué impide cerrar la lectura?

No convierta la tabla en una colección de etiquetas sin evidencia. Cada campo debe enlazar con una consulta, un registro o una decisión documentada. Si el sistema no ofrece el dato, use “no disponible” y describa el impacto. El lector debe distinguir entre cero, vacío, desconocido y no aplicable.

Cómo elegir la fuente sin ir más allá de su alcance

El modelo comienza en la pregunta y retrocede hasta el registro que puede responderla. Si se quiere saber cuántas unidades salieron de una familia en un turno, la fuente principal debería conservar orden, producto, cantidad y cierre de turno. Un cuadro agregado puede ser útil para orientar la búsqueda, pero no necesariamente contiene esas dimensiones.

OPC UA puede aparecer como interfaz de intercambio. Su especificación define conceptos, mensajes y modelos; no garantiza que el gateway conserve el estado, la unidad o la calidad del dato. La fuente oficial limita su alcance a la especificación y la conformidad del protocolo. La ficha debe añadir la evidencia local de implementación y prueba.

Los principios de gobierno de NIST ayudan a formular preguntas de procedencia y uso consistente. NIST presenta el gobierno de información manufacturera como un conjunto de principios para procesar y usar datos de forma repetible. Eso orienta la ficha, pero no convierte una consulta interna en una garantía de calidad.

La hoja de ruta de NIST sobre IA y fabricación señala retos de heterogeneidad, gestión de datos y operación que pueda explicarse. El documento es contexto de investigación, no evidencia de una instalación española ni de una automatización concreta. Evite usarlo para afirmar que un algoritmo interpreta el KPI por sí solo.

La guía técnica de ENISA puede servir para ordenar evidencias de acceso y registro cuando una organización esté dentro de su alcance. No certifica el cumplimiento NIS2 de una planta ni decide qué controles aplican. Si se consulta, registre el apartado y la autoridad que confirma su pertinencia nacional. La relación entre seguridad y contexto de KPI debe quedar separada del cálculo.

Procedimiento de diseño en seis pasos

1. Escriba la decisión que depende del KPI

Una buena ficha empieza con una decisión acotada: abrir una comprobación de datos, comparar dos ventanas o pedir el cierre de una orden. No empiece con “quiero ver la capacidad”. Pregunte qué debe cambiar en la conversación si el valor se confirma o si queda pendiente.

La decisión también delimita el nivel. Para una revisión de turno puede bastar una línea y una familia. Para una reunión de capacidad de planta quizá haga falta una agregación por recurso. No suponga que el contexto de un caso sirve para todos los informes.

2. Liste entidades y relaciones

Anote la entidad primaria y las referencias que permiten localizarla en cada sistema. Si una línea tiene nombres diferentes, conserve el alias y su fuente. Si la relación entre máquina y familia se obtiene de una tabla de planificación, registre la versión consultada.

No resuelva aquí los conflictos de identidad. Si dos códigos podrían apuntar al mismo recurso, marque la relación como provisional y derive la comprobación a la persona responsable. El modelo de contexto solo debe declarar qué se sabe y qué no.

3. Fije la ventana y el estado

Defina el periodo de negocio, la zona horaria y los estados incluidos. Escriba cómo se tratarán los registros abiertos, corregidos o recibidos tarde. Cuando una ventana sea una muestra parcial, no la llame turno completo en el título del KPI.

Si el estado se obtiene de otra tabla, cite la relación. Un valor de capacidad sin estado puede ser válido para una serie descriptiva, pero no para comparar disponibilidad y producción sin advertencia. La limitación debe viajar con el valor.

4. Documente medida, unidad y denominador

Copie la definición local del numerador y del denominador. Registre conversiones, redondeos y filtros. Si el KPI procede de una fórmula, incluya una expresión legible o un enlace a la consulta versionada.

No ajuste la fórmula para que coincida con una capacidad nominal. Cuando haya dos definiciones válidas, manténgalas separadas y use nombres que hagan visible la diferencia. La ficha busca comparabilidad explícita, no una única cifra cómoda.

5. Trace la fuente y la extracción

Indique el sistema original, la tabla o tag, la consulta y la fecha de extracción. Si el valor pasa por una interfaz, anote el mensaje o lote que lo transportó. Guarde la versión de la vista para poder reproducir la lectura después de una actualización.

Una estadística agregada de digitalización puede aportar contexto empresarial, como la encuesta TIC del INE, pero no demuestra que una planta tenga una arquitectura determinada. El propio alcance de la encuesta se refiere a empresas y no a la calidad de un KPI local. Use ese tipo de fuente para el marco, no para completar campos faltantes.

6. Revise y marque pendientes

Pida a otra persona que tome la ficha y localice el mismo valor. Si necesita una explicación oral para entender qué significa “capacidad”, falta contexto. Registre las preguntas que surgieron y conviértalas en pendientes con fecha de revisión.

La salida no tiene que ser “válida” o “inválida” en bloque. Puede ser interpretable para una familia y no comparable con otra; puede tener fuente confirmada y estado pendiente. La granularidad de la conclusión debe seguir la granularidad de la evidencia.

En la revisión del contexto, ordene cada registro por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión. Los principios de gobierno de información de NIST ayudan a conservar esa procedencia, pero no sustituyen la regla local.

Ejemplos de lectura sin inventar contexto

Imagine un informe que muestra 1.240 unidades para la línea 2. La ficha indica línea 2, familia A, turno B, unidades terminadas, fuente MES y consulta cerrada a las 22:00. Sin embargo, el estado de cambio de formato no está disponible. La lectura puede describir la salida registrada, pero no debe compararla con un turno que sí excluya cambios de formato.

En otro caso, la cifra procede de un contador OPC UA y se agrega en un servicio intermedio. El modelo conserva el tag, la unidad de origen, el factor de conversión y la consulta que agrupa por hora. También anota que no hay evidencia de cómo se representa un reinicio. La cifra puede servir para investigar, pero la interpretación del reinicio queda abierta.

Una tercera ficha combina una orden ERP con cantidades MES. El ERP aporta la familia comercial y el MES la salida por estación. La relación se basa en una clave de orden que cambia de formato en la interfaz. El modelo registra la transformación y exige comprobar un ejemplo en cada turno antes de presentar una capacidad agregada.

Estos ejemplos no son plantillas de datos reales. Sirven para mostrar por qué el contexto debe acompañar al valor. No asigne números, estados o familias a una planta que no los haya registrado. Una tabla de muestra en un procedimiento debe estar marcada como ilustrativa.

Errores que degradan la interpretación

El primer error es guardar solo el número final. Sin unidad y denominador, un valor de capacidad puede confundirse con producción acumulada. El segundo es usar el nombre del dashboard como si fuera la fuente. El nombre ayuda a encontrar la vista, pero no demuestra qué filtros aplicó.

También es frecuente mezclar fecha de evento y fecha de consulta. La diferencia puede explicar por qué una corrección aparece en un informe posterior. Otro error consiste en traducir todos los estados a “activo” y perder la distinción entre producir, esperar y cambiar de formato.

Un modelo puede fallar por exceso de confianza. Citar ISA-95, OPC UA o NIST no prueba que la instalación use esos modelos correctamente. Las referencias ordenan preguntas; la prueba sigue siendo el registro local, la configuración autorizada y la revisión de la persona que conoce el proceso.

Evite convertir la ficha en un inventario de propietarios o permisos. Esas cuestiones pueden ser relevantes para seguridad y gobierno, pero este contrato se ocupa del contexto del KPI. Enlace los controles pertinentes sin afirmar que el modelo resuelve el acceso.

Criterio de cierre y siguiente comprobación

La salida del modelo debe permitir identificar el valor, repetir la consulta y saber qué queda pendiente. Si falta entidad, ventana, estado, unidad o fuente, la ficha no debe cerrar una comparación de capacidad. La integración entre niveles descrita por ISA ayuda a localizar la autoridad del dato, pero no convierte el contexto en una certificación.

La salida del modelo debe dejar criterio, fuente y siguiente comprobación; si falta evidencia, mantenga la interpretación abierta. ISA aporta un lenguaje para ubicar preguntas entre niveles, no una aprobación de la cifra.

La siguiente acción puede ser pedir una extracción, revisar una tabla de equivalencias o confirmar una regla de turno. Escriba quién la hará y qué evidencia se espera. Si no existe una fuente con el campo necesario, cambie la decisión a una comprobación de disponibilidad y no a una explicación de rendimiento.

Límites de las referencias

OPC UA, ISA-95, NIST y ENISA aportan especificaciones, marcos o guías. Ninguna de esas fuentes certifica la calidad de un KPI local, prueba una latencia, confirma una capacidad nominal o autoriza una decisión de inversión. La encuesta del INE describe empresas agregadas y tampoco sustituye registros de planta.

Una especificación de protocolo no garantiza interoperabilidad, seguridad, latencia ni una implementación conforme; exige perfil, pruebas y revisión locales. OPC Foundation explica el alcance técnico de la referencia, que no debe convertirse en una conclusión sobre una fábrica concreta.

El modelo de contexto no calcula capacidad, no asigna responsabilidades ni demuestra cumplimiento de seguridad. Requiere datos locales, una consulta versionada y revisión humana. Cuando una afirmación dependa de un campo ausente, la respuesta correcta es mantenerla pendiente.

Para documentar el origen de los datos, consulta mapear fuentes de datos para un informe de producción. Si necesitas escoger entre varios sistemas, revisa identificar la fuente autoritativa para un KPI.

Para preparar una revisión de calidad, enlaza revisar calidad de datos antes de la capa de lectura. También puedes consultar el hub de datos industriales IT/OT y la guía de acceso a datos IT/OT industriales.

Preguntas frecuentes

¿Qué diferencia hay entre KPI y contexto?

El KPI es el valor o la serie calculada; el contexto explica la entidad, la ventana, el estado, la unidad y la fuente que hacen interpretable ese valor.

¿Debo incluir la familia de producto aunque el KPI sea de una línea?

Sí, cuando la línea fabrica familias con ciclos o restricciones distintas. Si no aplica, registra la razón y el alcance que excluye esa dimensión.

¿Qué hago si la fuente no conserva el estado operativo?

Marca el estado como pendiente, conserva la consulta y evita comparar el KPI con periodos que sí tengan estado confirmado.

¿OPC UA garantiza que mi KPI sea correcto?

No. OPC UA describe modelos y comunicación, pero la corrección del KPI depende de la implementación, la unidad, la cobertura y las pruebas autorizadas en la planta.

¿Cuándo puede cerrarse la ficha de contexto?

Cuando otra persona puede identificar el valor, repetir la consulta y entender sus límites sin pedir una explicación informal al autor.