Analítica de datos industriales: cómo exprimir los 18 meses de telemetría que nadie está mirando
Guía práctica para convertir la telemetría de tu planta, flota o data center en dashboards operativos, data warehouse y reportería ejecutiva. Stack honesto, errores típicos y cuándo cruzar a IA.
Si su operación lleva más de un año capturando telemetría —temperaturas, niveles, peso, consumo, eventos de máquina— probablemente tenga 18 meses de datos en InfluxDB o PostgreSQL que nadie está mirando. En paralelo, alguien sigue cerrando un Excel los lunes para el comité ejecutivo, y las áreas de operación no se hablan con las de planeación porque cada una tiene su propio reporte.
Ese hueco —entre la telemetría que ya tiene y la decisión ejecutiva que necesita tomar— es lo que llamamos analítica de datos industriales. No es un proyecto de “big data” ni un data lake corporativo de tres años. Es una capa práctica, en capas, que se monta sobre lo que ya capturó.
Las tres capas honestas
La trampa más común es mezclar todo en un solo dashboard “todo en uno”. No funciona porque las audiencias tienen necesidades diferentes:
[ Sensores / PLCs / ERP ]
↓
[ Tiempo real ] → Grafana → operador en piso (segundos)
↓
[ Histórico ] → Data warehouse / lakehouse → analista (semanas)
↓
[ Ejecutivo ] → Power BI / Metabase → comité (mes/trimestre)Cada capa vive separada pero conversa con las otras. El dashboard ejecutivo del lunes no consulta directamente la time-series que mueve millones de puntos por hora — eso lo tumbaría. Consulta el warehouse, que se materializa cada noche con datos agregados.
Capa 1 — Tiempo real (operación)
Grafana sobre InfluxDB o TimescaleDB. Vista por equipo, por línea o por sede. Es la que la guardia 24/7 deja abierta en pantalla. Refresca cada 30 segundos. Lleva alertas a Slack, WhatsApp o PagerDuty.
Lo que NO es: un dashboard para gerencia. La gerencia no necesita ver una serie de temperaturas en vivo; necesita un KPI.
Capa 2 — Histórico consolidado (análisis)
Es la que más se subestima. Aquí entra el data warehouse o lakehouse. Para arrancar, casi siempre recomendamos PostgreSQL + TimescaleDB con dbt para las transformaciones. Cuando el volumen supera ~50-100 millones de filas mensuales o se necesitan cruces con datos de ERP/CRM, salta a BigQuery o Snowflake.
La regla práctica: si su equipo está pagando más de USD 800/mes en consultas pesadas a la base operativa, ya tiene un caso de negocio para mover el análisis a un warehouse separado.
Capa 3 — Ejecutivo (decisión)
Power BI o Metabase sobre las tablas ya transformadas del warehouse. KPIs por sede, por línea, por SKU, por mes. Aquí viven el OEE, el MTBF, el costo por hora de planta caída, las mermas por sede.
La diferencia con Excel es que esta capa se construye una vez y se actualiza sola. Nadie cierra nada los lunes.
Stack que usamos (con honestidad de costos)
| Componente | Empezamos con | Cuando crece |
|---|---|---|
| Ingesta de PLCs/sensores | MQTT + gateway edge | Kafka Connect / Airbyte |
| Time-series operativa | InfluxDB o TimescaleDB | InfluxDB Cloud / Timescale Cloud |
| Warehouse analítico | PostgreSQL + dbt | BigQuery / Snowflake |
| Transformación | dbt | dbt + Airflow |
| Dashboard operativo | Grafana | Grafana Enterprise |
| Dashboard ejecutivo | Metabase (open source) | Power BI |
| Orquestación | cron + scripts | Apache Airflow / Prefect |
La columna izquierda cuesta menos de USD 200/mes en infra y soporta plantas de tamaño mediano. La columna derecha empieza alrededor de USD 1.500/mes pero soporta múltiples sedes y volúmenes altos.
Qué dashboard pide cada sector
| Sector | KPIs ejecutivos típicos |
|---|---|
| Manufactura | OEE por línea, scrap rate, tiempo entre cambios, cumplimiento de programa |
| Data center | Uptime por sala, capacity utilization, MTBF de HVAC, consumo PUE |
| Energía / Utilities | Pérdidas técnicas vs no técnicas, demanda vs generación, eventos por subestación |
| Logística | Costo por km, consumo por ruta, mermas por contenedor, on-time delivery |
| Oil & Gas | Inventario por tanque, reconciliación tanqueo-venta, derrames evitados |
| Cadena de frío | % tiempo en rango, rupturas por sede, tiempo a temperatura objetivo |
| Agroindustria | Yield por lote, costos por hectárea, anomalías ambientales |
Cada uno de estos KPIs nace del cruce entre la telemetría que ya capturó y los datos de su ERP o sistema de gestión. No es un proyecto nuevo de instrumentación — es exprimir lo que ya tiene.
Errores típicos (y cómo evitarlos)
- Empezar por el data warehouse sin tener telemetría confiable. Si los sensores tienen
nullel 20% del tiempo, el warehouse va a multiplicar la basura. Primero estabilice la captura, después consolide. - Mezclar tiempo real con histórico en el mismo dashboard. Va a sufrir consultas lentas y el operador no sabe qué mirar. Sepárelos.
- Dashboards sin dueño. Si nadie es responsable del dashboard de OEE, deja de actualizarse en 6 semanas. Cada dashboard necesita un dueño de negocio y un dueño técnico.
- Copiar el Excel ejecutivo a Power BI sin repensar. Si el Excel ya estaba mal, el Power BI estará mal con mejores colores. Aproveche el cambio para repensar qué decisión va a soportar cada KPI.
- Confundir BI con observabilidad. Grafana es excelente para ambos pero la mentalidad es distinta. Observabilidad mira “qué está pasando ahora”; BI mira “qué pasó este mes y por qué”.
- No documentar la lógica de transformación. Si tres meses después nadie sabe cómo se calcula el OEE, no tiene un KPI, tiene una opinión.
dbtresuelve esto bien.
Cuándo cruzar a IA
Con 6 meses o más de datos limpios y consistentes en el warehouse, ya tiene el insumo para empezar a hablar de predictivo. Antes de eso, los modelos van a aprender el ruido en lugar de la señal.
Los puentes naturales son:
- Forecasting de demanda, consumo o generación → modelos clásicos (Prophet, ARIMA) suelen bastar.
- Detección de anomalías sobre series de tiempo → isolation forest o autoencoder simple.
- Computer vision sobre el CCTV existente → si ya tiene cámaras, no necesita comprar más hardware.
Esto lo cubrimos en detalle en el siguiente post: IA aplicada a IoT industrial.
Y si su sitio está en zona rural y se preocupa por subir tanto dato a la nube, hay una salida: edge inference sobre conectividad multi-Starlink procesa local y solo sube los eventos importantes.
Caso real: del Excel a OEE en línea
El cliente del caso de cadena de frío llegó con 18 meses de InfluxDB y un Excel ejecutivo que se cerraba los lunes. En 6 semanas implementamos:
- TimescaleDB consolidando 4 sedes (antes vivían separadas).
- dbt con 12 modelos de transformación documentados.
- Metabase con 3 dashboards: operativo (sede), gerencial (regional) y ejecutivo (consolidado).
- Reporte semanal automático a Teams cada lunes 7am.
El Excel sigue existiendo, pero ahora se llena solo. El tiempo del analista que lo armaba (4-6 horas semanales) pasó a investigar mermas — donde sí agrega valor.
Checklist antes de pedir una propuesta
Antes de pedirnos (o pedirle a cualquiera) una propuesta de analítica, tenga claro:
- ¿Cuántos meses de datos limpios tiene hoy?
- ¿Quién es el dueño de negocio de cada dashboard que pediría?
- ¿Qué decisión va a tomar cada audiencia con ese dashboard?
- ¿Cuáles son sus 5 KPIs más importantes? (si la respuesta es “todos”, no son KPIs)
- ¿Necesita integrar con ERP/CRM existente? ¿cuál?
- ¿Hay restricciones de dónde pueden vivir los datos (on-premise vs cloud)?
- Presupuesto mensual de infra aceptable
- ¿Quién mantendrá los dashboards una vez entregados?
Cómo seguir
Si tiene telemetría capturada y siente que no la está exprimiendo, escríbanos a info@col0.com o por WhatsApp. En la primera reunión miramos su stack actual y le decimos honestamente si vale la pena montar un warehouse ahora o si conviene esperar.
Más detalle del servicio en Analítica de datos industriales, y si su próximo paso es predictivo, el post de IA aplicada a IoT industrial cubre los cuatro patrones que sí funcionan en producción.