El dashboard industrial estaba impecable. Doce gráficos. Colores. Datos actualizándose en tiempo real. Había costado meses de trabajo de IT y una inversión considerable en licencias.
El problema: nadie del turno lo miraba. Las decisiones se seguían tomando por experiencia, radio y criterio del supervisor de turno. El dashboard industrial estaba online. La operación estaba offline.
Este artículo describe qué pasó cuando se hizo el diagnóstico, qué se rediseñó y por qué el resultado fue un tablero que el operador consulta por iniciativa propia al empezar cada turno. Sin que nadie se lo pida.
El error de diseñar el dashboard industrial para IT en vez de para operaciones
La mayoría de los dashboards industriales se construyen respondiendo la pregunta equivocada. IT pregunta: ¿qué datos tenemos disponibles? Y muestra todo lo que puede mostrar.
La pregunta que debería guiar el diseño es diferente: ¿qué decisión necesita tomar el operador de turno en los próximos 30 minutos? Esa pregunta no la hace IT. La hace alguien que entiende la operación.
El resultado de diseñar desde la disponibilidad de datos y no desde la necesidad de decisión es siempre el mismo: un dashboard industrial con mucha información y poca relevancia operativa. El tablero muestra todo lo que existe. No muestra lo que importa.
Esto no es un problema de competencia del equipo de IT. Es un problema de enfoque. El KPI correcto para un dashboard industrial no es el que el sistema puede calcular: es el que cambia una decisión cuando cruza un umbral.
El diagnóstico: de 12 gráficos, solo 2 eran accionables
El primer paso del rediseño fue hacer una pregunta simple para cada uno de los 12 gráficos del dashboard industrial: ¿qué hace el operador cuando este gráfico sale del rango esperado?
En 10 de los 12 gráficos, la respuesta fue: «lo anota» o «llama a alguien» o «espera a ver si se normaliza». Ninguna de esas respuestas es un protocolo. Son reacciones individuales no documentadas.
Solo 2 gráficos tenían una respuesta concreta: cuando ese número baja de X, el operador hace Y. Esos 2 eran los únicos que estaban cumpliendo la función de un dashboard industrial real. Los otros 10 eran información de contexto que nadie había pedido explícitamente y que nadie usaba de forma sistemática.
El diagnóstico fue claro: el tablero no fallaba técnicamente. Fallaba estratégicamente. Había sido construido para mostrar, no para decidir.
El rediseño del dashboard industrial: menos gráficos, más decisiones
El rediseño no empezó agregando métricas. Empezó eliminando.
Paso 1: identificar las 3 decisiones críticas del turno
Con el equipo de operaciones se mapearon las tres decisiones que el supervisor de turno toma todos los días y que tienen mayor impacto en el resultado: cuándo escalar una parada a mantenimiento, cuándo ajustar velocidad de línea por desvío de calidad y cuándo activar el protocolo de cambio de formato.
Esas tres decisiones definieron las tres métricas que el dashboard industrial tenía que mostrar. No doce. Tres.
Paso 2: asignar umbral, alerta y protocolo a cada métrica
Para cada una de las tres métricas se definió:
Umbral: el valor exacto que, cuando se cruza, requiere acción. No un rango vago. Un número concreto acordado con el equipo de operaciones y mantenimiento.
Alerta: cómo llega la señal al responsable. En este caso, notificación automática al supervisor de turno con descripción del evento y el contexto asociado — producto en proceso, tiempo transcurrido, historial reciente.
Protocolo: qué hace exactamente el responsable cuando recibe la alerta. Documentado. Sin ambigüedad. Sin margen para que cada supervisor interprete a su criterio.
El sistema Smart Factory de MOX IT permite configurar esta lógica directamente sobre los datos existentes: umbral, responsable y protocolo asociado a cada métrica, sin reemplazar el sistema de captura.
Paso 3: rediseñar la pantalla desde la lógica del turno
El dashboard industrial rediseñado tiene tres métricas en la parte superior — las tres decisiones críticas — con indicador de estado claro: verde, amarillo, rojo. Sin ambigüedad visual.
Debajo, información de contexto disponible para quien la necesite, pero no en el primer plano. El operador no tiene que procesar 12 gráficos para entender el estado de la línea. Mira tres números y sabe exactamente si hay algo que requiere acción.
El resultado: el tablero que el operador consulta sin que nadie se lo pida
Seis semanas después del rediseño, el comportamiento cambió sin que nadie lo instruyera explícitamente. El operador de turno empezó a consultar el dashboard industrial al inicio de cada turno como primer paso antes de hacer la ronda de línea.
No porque alguien se lo pidiera. Porque el tablero le decía algo útil en 10 segundos: si hay algo fuera de rango que requiere atención antes de arrancar, o si todo está en condición y puede hacer su recorrido normal.
Los resultados medibles en ese período:
Tiempo de detección de desvío: de horas a minutos. Antes, los desvíos se detectaban cuando el supervisor hacía la ronda o cuando alguien lo notaba. Después, el sistema alertaba antes de que el desvío tuviera tiempo de impactar en el producto.
Consulta sistemática: de esporádica a cada turno. El OEE del turno pasó a revisarse en los primeros 10 minutos, no al día siguiente en la reunión de producción.
Decisiones documentadas: cada acción tomada a partir de una alerta quedó registrada en el sistema. Por primera vez, había trazabilidad de por qué el operador había tomado una decisión de turno.
En resumen, esto significa que:
- Un dashboard industrial efectivo no muestra todo lo disponible: muestra lo que activa una decisión concreta.
- El error más común es diseñar el dashboard industrial desde IT — qué datos hay — en vez de desde operaciones — qué decisión necesita el turno.
- Un buen rediseño reduce gráficos y aumenta acciones: menos pantalla, más decisión.
- Cada métrica crítica del dashboard industrial debe tener umbral, alerta y protocolo asociado. Sin esos tres elementos, es información decorativa.
- La prueba de un tablero funcional: el operador lo consulta al empezar turno sin que nadie se lo pida.
- El problema del dashboard industrial que nadie mira no es técnico. Es de diseño. Y tiene solución sin reemplazar el sistema existente.
Antes de invertir en rediseñar tu dashboard industrial, preguntate:
¿Cuántos de tus gráficos tienen un protocolo de acción asociado? Si la mayoría no lo tiene, el problema no es la cantidad de datos sino la ausencia de diseño decisional.
¿Tu dashboard industrial fue diseñado desde las necesidades del turno o desde la disponibilidad de datos del sistema? La respuesta a esa pregunta explica por qué se usa o no se usa.
¿El operador consulta el tablero por iniciativa propia al inicio del turno? Si necesita que alguien se lo recuerde, el tablero no está siendo útil todavía.
¿Si eliminás la mitad de los gráficos, qué decisiones dejarías de tomar? Si la respuesta es «ninguna», esos gráficos no son métricas de gestión. Son ruido visual.
Si tu tablero lleva meses online y nadie cambió una decisión por lo que muestra
El problema no es el dashboard industrial. Es el diseño. Los datos probablemente están bien capturados. Lo que falta es la capa que conecta cada métrica con una decisión, un responsable y un protocolo.
Eso se puede diagnosticar en una sesión técnica. Sin reemplazar el sistema. Sin un proyecto de meses. Con una pregunta por cada gráfico: ¿qué hace el operador cuando esto sale del rango?
Si la respuesta no es inmediata y concreta, ahí está la brecha.
