Cuando dirección pregunta de dónde sale un KPI agregado, responder con una captura del tablero no basta. La cifra final quizá sea correcta, pero el tablero suele ocultar los pasos intermedios: una lectura llega desde un sensor, un sistema la asocia a un activo, otra capa decide si representa producción, una consulta la une a una orden y una regla suma o divide resultados dentro de una ventana. Si cualquiera de esos pasos cambia, el mismo sensor puede acabar en un KPI distinto.
Construir trazabilidad significa poder recorrer ese camino en ambos sentidos. Hacia atrás, una persona debe poder partir del total publicado y localizar las lecturas, eventos y reglas que lo formaron. Hacia delante, debe poder tomar una lectura concreta y saber si entró en un informe, en qué versión y con qué efecto. No hace falta diseñar toda la arquitectura IT/OT para conseguirlo. Hace falta definir un contrato de evidencia alrededor del KPI que importa.
ISO 22400-1 define un marco independiente del sector para definir, componer, intercambiar y usar KPI de gestión de operaciones de fabricación en industrias por lotes, continuas y discretas. La ficha pública de ISO 22400-1 no prescribe el modelo de datos de una planta ni convierte una lectura en buena. Sí sitúa la definición y composición del indicador dentro del problema que hay que gobernar.
Esta guía se concentra en un caso concreto: mantener la ruta desde una lectura de sensor, sus transformaciones y su agregación hasta un informe de producción. No sustituye la calibración de instrumentos, la liberación de calidad, los procedimientos de ciberseguridad, los requisitos regulatorios ni las reglas contables. Si el KPI afecta a una decisión de seguridad, calidad regulada, contrato o cierre financiero, la organización debe aplicar también sus controles y responsables específicos.
Empiece por el KPI que hay que explicar
Un proyecto de datos suele arrancar preguntando qué señales existen. Para una revisión de dirección, el orden útil es el contrario: escriba primero qué decisión se va a tomar y qué KPI debe sostenerla. “Producción buena por turno”, “unidades completadas por línea” o “consumo por unidad conforme” parecen parecidos, pero no exigen la misma evidencia.
El título del KPI no es una definición. Antes de conectar registros, documente al menos el numerador, el denominador si existe, la unidad, la ventana temporal, los activos incluidos, el criterio de calidad y el propósito de uso. Si la cifra solo es una lectura provisional para priorizar una comprobación, puede tolerar una cobertura distinta a la de un dato que respaldará una factura o un compromiso de entrega. Esa diferencia debe quedar escrita antes de ver el resultado.
ISO 22400-2 presenta KPI de operaciones mediante su fórmula, sus elementos, comportamiento temporal, unidad o dimensión y otras características. La descripción de ISO 22400-2 explica ese alcance. Para quien construye linaje, esos campos se convierten en preguntas de control: ¿qué elemento nació de una medición?, ¿qué transformación le dio significado?, ¿en qué intervalo entra y con qué unidad se agregó?
Una definición manejable puede tener esta forma: “Unidades buenas de la línea L-03 entre las 06:00 y las 13:59, hora local de planta, calculadas como unidades de salida confirmadas que superan el criterio de aceptación vigente; excluye pruebas de puesta a punto identificadas con el estado PRUEBA”. No es todavía una implementación. Es el contrato que permite decidir qué datos deben poder localizarse después.
Distinga lectura, evento y KPI
Una lectura es un valor recibido con una procedencia técnica. Puede ser un pulso de fotocélula, una masa, un contador acumulado, una temperatura o un estado de máquina. Que exista no significa que represente una unidad producida. Un contador puede reiniciarse; una señal puede duplicarse por rebote; un valor puede llegar tarde; una misma pieza puede activar más de un punto de medida.
Un evento es la interpretación operativa que el sistema asigna a una o varias lecturas bajo una regla explícita. Por ejemplo, dos pulsos en una ventana pueden convertirse en “salida de unidad”, o un cambio de estado puede convertirse en “inicio de parada”. La regla debe tener nombre y versión, porque cambiar un filtro o una tolerancia cambia el evento aunque el valor original sea idéntico.
El KPI es una agregación de eventos o de mediciones ya contextualizadas. Puede contar eventos, sumar cantidades, calcular una razón o comparar con un objetivo. Es el último eslabón de esta página, no el primero. Cuando se confunden las tres capas, la discusión se atasca en frases como “el sensor dice 12 000”. Un sensor aporta una señal; la organización decide qué significa en el cálculo.
ISO/TR 22400-10 contiene descripciones para el uso práctico de fórmulas de ISO 22400-2 en control y monitorización de producción, incluida la secuencia operativa de adquisición de datos. La ficha de ISO/TR 22400-10 no publica una receta universal para cada instrumento. Sirve como recordatorio de que la adquisición y la aplicación del KPI deben estar conectadas, no descritas como mundos separados.
| Capa | Pregunta que resuelve | Evidencia mínima que conviene guardar |
|---|---|---|
| Lectura | ¿Qué recibió el sistema? | Id de fuente, activo, valor, unidad, timestamp de origen y estado de recepción |
| Evento | ¿Qué hecho operativo representa? | Regla y versión, ids de entrada, timestamp del evento, estado y motivo de descarte |
| Contexto | ¿Dónde encaja el hecho? | Línea, orden, receta, turno, producto y vigencia de cada asignación |
| KPI | ¿Cómo contribuye al resultado? | Regla de agregación, ventana, filtros, versión y id de informe |
La tabla no obliga a que cada dato viaje a una base central. Describe una relación que debe ser recuperable. Una planta puede conservar la lectura en el historiador, el evento en un servicio de operaciones y la regla en un repositorio versionado. Lo importante es que los identificadores permitan cruzar esas piezas sin inventar enlaces después de una incidencia.
Dé identidad a cada lectura sin prometer más precisión de la disponible
El primer punto débil del linaje suele ser la identidad. Una fila con “sensor A, 10:15, valor 1” no ayuda mucho si hay varios PLC, relojes desalineados o reintentos de comunicación. Asigne un identificador estable que pueda apuntar a la recepción original, incluso si el proveedor ya trae un identificador propio. Conserve ambos cuando sea posible.
La marca temporal también necesita contexto. Guarde el tiempo de origen, el instante de recepción y, si se transforma después, el instante de proceso. No los use como si fueran sinónimos. El tiempo de origen ayuda a ubicar el hecho físico; la recepción puede revelar una cola o una desconexión; el proceso permite repetir una ejecución. Si la fuente solo ofrece minuto, no afirme una secuencia por segundos.
La unidad y el punto de medida cierran la identificación. “125” puede ser un conteo de piezas, metros, kilogramos o un acumulado desde el arranque. Documente si el valor es incremental o acumulativo, si admite reinicios y si se espera una lectura negativa. Estas notas parecen básicas hasta que un reinicio del contador se interpreta como una pérdida de producción.
No convierta este registro en un expediente imposible de mantener. El nivel de detalle depende del riesgo de la decisión y de la posibilidad real de recuperación. Si no se pueden retener valores brutos durante años, conserve un resumen verificable, el intervalo del que procede y la política de retención. La honestidad aquí importa: no diga que el informe puede reconstruirse a lectura individual si esa evidencia ya no existe.
Haga visible cada transformación
Las transformaciones son necesarias. Convertir milisegundos a minutos, deduplicar mensajes, interpolar un estado, restar un contador anterior o asociar una señal con una orden puede ser razonable. El riesgo aparece cuando se presenta el resultado como dato directo del sensor y se pierde la regla que lo produjo.
Para cada transformación material, registre cinco cosas: el identificador de entradas, la versión de la lógica, los parámetros usados, el resultado y el motivo de una exclusión o corrección. Una versión puede ser un hash de consulta, una etiqueta de despliegue o un número de regla aprobado. Debe ser suficiente para saber si el cálculo de ayer y el de hoy usaron la misma interpretación.
Piense en una lectura de contador acumulado. Para obtener unidades del intervalo, una rutina resta el valor inicial del final. Si el contador se reinició, la resta produce un negativo y la rutina quizá cambia de método. Ese cambio debe aparecer en el linaje: lecturas A y B, regla de diferencia v3, detección de reinicio, resultado C y motivo “reinicio documentado”. Sustituir silenciosamente B por un valor ajustado hace que la próxima revisión empiece sin saber qué sucedió.
La corrección manual merece una ruta separada. Una persona puede corregir un registro por un fallo conocido, pero el sistema debe conservar el valor recibido, el valor corregido, el motivo, la autorización y el KPI afectado. La corrección no es un pecado; ocultarla sí debilita la capacidad de explicar una cifra.
La recomendación de NIST sobre trazabilidad y fiabilidad de datos de fabricación trata orientaciones prácticas para desplegar sistemas que mantengan trazabilidad de datos y contempla representaciones basadas en archivos y en flujos. El resumen oficial de NIST AMS 300-10 delimita además su alcance a determinados procesos de fabricación sustractiva y aditiva. No prueba que un diseño concreto sea suficiente para una línea general de producción; sí evita asumir que la trazabilidad solo corresponde a ficheros o solo a datos en tiempo real.
Añada el contexto operativo sin inventarlo
Una lectura no sabe por sí misma a qué orden, producto o turno pertenece. Esa relación viene de otras fuentes y puede cambiar con retrasos de registro. Trate el contexto como dato con vigencia, no como una etiqueta permanente pegada al sensor.
En una línea que cambia de producto, una señal a las 10:02 puede pertenecer a una orden y la de las 10:08 a otra. Para asignarlas, el cálculo debe declarar la regla: tomar el estado activo en ese instante, usar un evento confirmado de cambio, aplicar una ventana de transición o marcar el dato como no asignado. Elegir una regla después de ver cuál mejora el KPI no es trazabilidad; es ajuste retrospectivo.
El contexto mínimo depende del indicador. Para unidades buenas, puede requerir activo, orden, producto, criterio de aceptación y turno. Para consumo por unidad, añade la fuente de energía, el periodo del medidor y la relación con la producción. Para una tasa de disponibilidad, añade estados y reglas de clasificación de paradas. Mantenga la página centrada en el KPI elegido: no haga que todos los datos de la planta deban atravesar el mismo modelo.
La investigación de NIST sobre una arquitectura de referencia para hilo digital señala la dificultad inherente de agregar y aplicar contexto a datos de sistemas heterogéneos a lo largo del ciclo de vida. El resumen de la publicación presenta una arquitectura de cuatro niveles y una implementación prototipo, no un mandato para adoptar ese diseño. Su lección práctica es más pequeña: cuando el contexto procede de varios sistemas, el informe debe poder declarar cuál usó y en qué momento.
Defina la agregación como una regla auditable
Llegados a este punto, ya hay lecturas identificadas, eventos interpretados y contexto. Falta explicar cómo pasan a ser un número. La regla de agregación debe señalar la ventana, los filtros, las agrupaciones, la unidad de salida y el tratamiento de datos incompletos.
Una regla de “unidades buenas por turno” puede sumar solo eventos de salida que tengan estado aceptado, pertenezcan a L-03, estén dentro del intervalo definido y no estén en modo de prueba. Si un evento llega 20 minutos tarde, la definición debe decidir si entra en una revisión del turno anterior o en el informe actual. Si dos fuentes informan la misma unidad, debe aclarar cuál prevalece o cómo se detecta la duplicación.
No esconda las exclusiones bajo el nombre de limpieza. Muestre cuántos eventos quedaron fuera por falta de activo, orden, unidad o estado de calidad. Una cifra con diez exclusiones documentadas puede ser más útil que una cifra aparentemente exacta que borró las mismas filas. Para una decisión sensible, el responsable necesita saber el tamaño y la naturaleza de esa cobertura incompleta.
La investigación de NIST sobre gráficos para hilos digitales describe un método para enlazar y trazar datos del ciclo de vida mediante grafos, con una implementación prototipo y un caso de estudio entre diseño, fabricación y calidad. La publicación de NIST también señala que no existe un método uniforme y generalizado para desplegar datos enlazados en fabricación. No hace falta adoptar un grafo para un único KPI; la decisión depende de la complejidad de las relaciones. Lo indispensable es que la relación entre entradas, regla y resultado sea recuperable.
| Elemento de la agregación | Pregunta de revisión | Ejemplo de evidencia |
|---|---|---|
| Ventana | ¿Qué inicio, fin y zona horaria se aplicaron? | Id de cierre y timestamps de la ejecución |
| Población | ¿Qué eventos podían entrar? | Consulta o regla versionada y filtros declarados |
| Agrupación | ¿Por línea, orden, producto o turno se sumó? | Claves de agrupación guardadas con el resultado |
| Unidad | ¿El total conserva una unidad coherente? | Regla de conversión y unidad final |
| Exclusiones | ¿Qué quedó fuera y por qué? | Conteo por motivo y lista de ids recuperable |
| Versión | ¿Se puede repetir la misma definición? | Hash de consulta, versión de servicio o etiqueta aprobada |
Pruebe la ruta con una muestra incómoda
No intente demostrar el linaje leyendo millones de filas en una reunión. Elija muestras que suelen romper reglas: una lectura cerca del corte, un contador que se reinicia, un cambio de orden, un dato tardío, una corrección manual y un evento que queda sin contexto. La prueba no busca culpables. Busca saber si el recorrido existe y si la definición trata los casos límite de la misma forma cada vez.
Empiece por el total publicado. Seleccione una contribución concreta y siga el resultado hacia atrás hasta los eventos. Desde cada evento, localice las lecturas y transformaciones. Compruebe que sus timestamps, unidades y activos concuerdan con la regla. Después avance hacia delante desde una de esas lecturas: confirme si entró en el evento esperado, en qué contexto cayó y qué contribución hizo al KPI. Si un paso depende de una hoja local o de la memoria de una persona, anótelo como dependencia, no como evidencia.
Una prueba sencilla también debe comprobar la repetición. Ejecute la regla con el mismo corte, las mismas entradas y la misma versión. El resultado debe ser igual. Si cambia porque se reemplazó una fuente, porque una dimensión se actualizó o porque se incorporó un dato tardío, emita una nueva versión de resultado y explique qué cambió. Un KPI revisado puede ser legítimo; un KPI revisado que conserva el mismo identificador sin aviso es difícil de defender.
Separe la trazabilidad de la confianza metrológica
Un linaje perfecto puede llevar un valor impreciso. Si una fotocélula está mal ajustada, si un contador pierde pulsos o si el punto de medida no representa la salida aceptada, poder recorrer la ruta no arregla el problema. Por eso conviene mantener dos preguntas separadas: “¿de dónde salió la cifra?” y “¿la medición es apta para este uso?”.
La primera se resuelve con identificadores, reglas y evidencias de transformación. La segunda requiere el programa de calibración, mantenimiento, pruebas de plausibilidad, controles de calidad y criterio técnico aplicable al instrumento. El informe puede enlazar ambos mundos, por ejemplo mostrando que una fuente estaba bajo revisión. No debe inferir que una cadena de hashes certifica el instrumento.
También hay un límite organizativo. El equipo de operaciones puede explicar la ruta de un KPI y declarar su cobertura, pero no debe usar esa explicación para liberar producto, certificar una medición o resolver una obligación regulatoria fuera de su autoridad. Cuando el dato afecta a esos ámbitos, la salida correcta puede ser una escalada, no una cifra más pulida.
Mantenga un registro que sobreviva al cambio
La trazabilidad se pierde con frecuencia al cambiar una consulta, sustituir un PLC, renombrar una línea o actualizar un modelo de datos. Antes de cada cambio material, registre qué versiones de KPI e informes quedarán afectadas y qué ocurre con la comparabilidad histórica. Un identificador de activo puede requerir una tabla de correspondencia; una nueva fórmula puede requerir recalcular una serie o mostrar dos definiciones durante una transición.
No todos los cambios merecen el mismo proceso. Corregir un literal en una etiqueta no tiene el mismo riesgo que alterar el filtro de calidad. Establezca una clasificación proporcional: cambios que solo mejoran la presentación, cambios que alteran el linaje pero no el cálculo, y cambios que pueden modificar el KPI. Los últimos deben aprobarse antes de usarse, conservar una fecha de vigencia y dejar una nota visible en los informes afectados.
El siguiente control es de acceso. Quien puede modificar una regla, una asignación de contexto o un dato corregido puede cambiar el resultado. La trazabilidad no exige bloquear todas las ediciones, pero sí saber quién las hizo, cuándo, con qué motivo y qué versión produjo. Combine ese registro con las políticas de acceso de la organización; esta guía no define una política de seguridad.
Qué entregar cuando dirección pide la ruta
La respuesta más útil suele caber en una página de evidencia y unas muestras recuperables. Entregue la definición del KPI, el periodo, la versión de cálculo, las fuentes de lectura, las transformaciones materiales, las reglas de contexto, las exclusiones y un enlace o identificador para revisar contribuciones. Añada una nota clara de límites: qué no se conserva, qué llega con retraso y qué controles quedan fuera de este informe.
No entregue un diagrama decorativo sin identificadores. Tampoco convierta el informe ejecutivo en una consola de ingeniería. La persona que toma una decisión necesita saber qué representa el número y dónde puede pedir detalle; la persona que lo revisa necesita poder llegar hasta la evidencia. Esas dos necesidades se resuelven con niveles de detalle distintos sobre la misma ruta.
Antes de publicar o usar un KPI, compruebe lo siguiente:
- ¿La definición nombra el hecho, la ventana, la unidad, el contexto y la regla de agregación?
- ¿Una muestra permite ir desde el total hasta una lectura de origen y volver al informe?
- ¿Cada transformación material conserva entradas, versión, parámetros y resultado?
- ¿Las exclusiones, correcciones y datos tardíos aparecen como tales en lugar de desaparecer?
- ¿El informe separa la trazabilidad del dato de su validación metrológica, de calidad o regulatoria?
Si falta una respuesta, etiquete el KPI como provisional o limite la decisión que puede respaldar. Después de construir la ruta, conviene revisar cómo documentar una definición de KPI compartido para que la regla no cambie entre áreas. Si la duda está en la ventana temporal, la guía para validar la hora de corte de un informe de producción aborda ese contrato distinto.
Preguntas frecuentes
¿Qué información debe vincular una lectura con un KPI?
Como mínimo, identificador de lectura, activo o punto de medida, marca temporal y unidad, además de la transformación aplicada, el contexto de producción, la versión de la regla de agregación y el identificador del informe. Los campos exactos dependen del proceso, pero deben permitir recorrer la ruta hacia atrás.
¿Hay que guardar todos los valores brutos del sensor?
Depende de la finalidad, la capacidad de almacenamiento y las obligaciones aplicables. Si no se conserva el valor original, el informe debe declarar qué resumen quedó, cómo se obtuvo y qué comprobación alternativa permite revisar el KPI. No conviene prometer una reconstrucción que la retención no permite.
¿Una transformación invalida la lectura original?
No. Una transformación puede convertir una unidad, filtrar una señal, asignar un estado o corregir un error documentado. Debe conservar el identificador de entrada, la versión de la transformación, sus parámetros y el resultado, para distinguir el hecho recibido de su interpretación operativa.
¿Puede un KPI usar datos de varios sensores?
Sí, si declara cómo sincroniza el tiempo, cómo resuelve unidades, qué activos y órdenes relaciona y qué hace cuando una fuente falta. Un total que mezcla fuentes sin esas reglas no es fácilmente revisable.
¿El linaje de datos sustituye la calibración del sensor?
No. El linaje explica de dónde salió una cifra y qué tratamiento recibió. La calibración, el mantenimiento y la validación metrológica determinan si la medición es apta para el uso previsto; deben mantenerse como controles separados.