Analítica de dados industriais: como aproveitar os 18 meses de telemetria que ninguém está olhando

Se sua operação já vem capturando telemetria há mais de um ano — temperaturas, níveis, peso, consumo, eventos de máquina — provavelmente tem 18 meses de dados no InfluxDB ou PostgreSQL que ninguém está olhando. Em paralelo, alguém continua fechando uma planilha Excel toda segunda para o comitê executivo, e as áreas de operação não conversam com planejamento porque cada uma tem seu próprio relatório.

Esse vão — entre a telemetria que você já tem e a decisão executiva que precisa tomar — é o que chamamos de analítica de dados industriais. Não é um projeto de “big data” nem um data lake corporativo de três anos. É uma camada prática, em camadas, montada sobre o que você já capturou.

As três camadas honestas

A armadilha mais comum é misturar tudo em um único dashboard “tudo em um”. Não funciona porque as audiências têm necessidades diferentes:

[ Sensores / PLCs / ERP ]
          ↓
[ Tempo real  ]  → Grafana → operador no chão (segundos)
          ↓
[ Histórico   ]  → Data warehouse / lakehouse → analista (semanas)
          ↓
[ Executivo   ]  → Power BI / Metabase → comitê (mês/trimestre)

Cada camada vive separada mas conversa com as outras. O dashboard executivo de segunda não consulta diretamente a time-series que move milhões de pontos por hora — isso derrubaria. Consulta o warehouse, que se materializa toda noite com dados agregados.

Camada 1 — Tempo real (operação)

Grafana sobre InfluxDB ou TimescaleDB. Visão por equipamento, por linha ou por site. É a que a guarda 24/7 deixa aberta em um painel. Atualiza a cada 30 segundos. Envia alertas para Slack, WhatsApp ou PagerDuty.

O que NÃO é: um dashboard para a diretoria. A diretoria não precisa ver uma série de temperaturas ao vivo; precisa de um KPI.

Camada 2 — Histórico consolidado (análise)

A camada mais subestimada. Aqui mora o data warehouse ou lakehouse. Para começar, quase sempre recomendamos PostgreSQL + TimescaleDB com dbt para as transformações. Quando o volume passa de ~50-100 milhões de linhas por mês, ou quando é preciso cruzar com ERP/CRM, salta para BigQuery ou Snowflake.

Regra prática: se sua equipe gasta mais de USD 800/mês em consultas pesadas contra a base operacional, já tem caso de negócio para mover a análise a um warehouse separado.

Camada 3 — Executivo (decisão)

Power BI ou Metabase sobre as tabelas já transformadas no warehouse. KPIs por site, por linha, por SKU, por mês. Aqui vivem o OEE, o MTBF, o custo por hora de planta parada, as perdas por site.

A diferença vs. Excel é que essa camada é construída uma vez e se atualiza sozinha. Ninguém fecha nada às segundas.

Stack que usamos (com honestidade de custos)

Componente	Começamos com	Quando cresce
Ingestão de PLCs/sensores	MQTT + gateway edge	Kafka Connect / Airbyte
Time-series operacional	InfluxDB ou TimescaleDB	InfluxDB Cloud / Timescale Cloud
Warehouse analítico	PostgreSQL + dbt	BigQuery / Snowflake
Transformação	dbt	dbt + Airflow
Dashboard operacional	Grafana	Grafana Enterprise
Dashboard executivo	Metabase (open source)	Power BI
Orquestração	cron + scripts	Apache Airflow / Prefect

A coluna esquerda custa menos de USD 200/mês em infraestrutura e suporta plantas de porte médio. A coluna direita começa em torno de USD 1.500/mês mas suporta múltiplos sites e volumes altos.

Qual dashboard cada setor pede

Setor	KPIs executivos típicos
Manufatura	OEE por linha, taxa de refugo, tempo entre setups, aderência ao plano
Data center	Uptime por sala, utilização de capacidade, MTBF de HVAC, PUE
Energia / Utilities	Perdas técnicas vs não técnicas, demanda vs geração, eventos por subestação
Logística	Custo por km, consumo por rota, perdas por contêiner, on-time delivery
Oil & Gas	Inventário por tanque, reconciliação abastecimento-venda, derrames evitados
Cadeia fria	% tempo em faixa, rupturas por site, tempo até temperatura alvo
Agronegócio	Yield por lote, custo por hectare, anomalias ambientais

Cada um desses KPIs nasce do cruzamento entre a telemetria que você já captura e os dados do seu ERP ou sistema de gestão. Não é um projeto novo de instrumentação — é aproveitar o que você já tem.

Erros típicos (e como evitá-los)

1. Começar pelo data warehouse sem ter telemetria confiável. Se os sensores retornam null 20% do tempo, o warehouse vai multiplicar o lixo. Estabilize a captura primeiro, consolide depois.
2. Misturar tempo real e histórico no mesmo dashboard. Consultas lentas e o operador sem saber o que olhar. Separe.
3. Dashboards sem dono. Dashboard sem dono de negócio para de ser atualizado em 6 semanas. Cada dashboard precisa de dono de negócio e dono técnico.
4. Copiar a planilha executiva para o Power BI sem repensar. Se a planilha já estava errada, o Power BI vai estar errado com cores melhores. Use a migração para repensar qual decisão cada KPI sustenta.
5. Confundir BI com observabilidade. Grafana é ótimo para ambos mas a mentalidade é diferente. Observabilidade pergunta “o que está acontecendo agora”; BI pergunta “o que aconteceu este mês e por quê”.
6. Não documentar a lógica de transformação. Três meses depois, se ninguém sabe como o OEE é calculado, você não tem um KPI, tem uma opinião. dbt resolve bem isso.

Quando dar o passo para IA

Com seis meses ou mais de dados limpos e consistentes no warehouse, você já tem o insumo para começar a falar de preditivo. Antes disso, os modelos vão aprender o ruído em vez do sinal.

Pontes naturais:

• Forecasting de demanda, consumo ou geração → modelos clássicos (Prophet, ARIMA) costumam bastar.
• Detecção de anomalias sobre séries temporais → isolation forest ou autoencoder simples.
• Visão computacional sobre o CCTV existente → se já tem câmeras, não precisa de hardware novo.

Cobrimos isso em detalhe no próximo post: IA aplicada a IoT industrial.

E se seu site fica em zona rural e você se preocupa em subir tanto dado para a nuvem, há uma saída: edge inference sobre conectividade multi-Starlink processa local e só sobe os eventos importantes.

Caso real: do Excel ao OEE ao vivo

O cliente do caso de cadeia fria chegou com 18 meses de InfluxDB e uma planilha executiva fechada toda segunda. Em 6 semanas implantamos:

• TimescaleDB consolidando 4 sites (antes viviam em silos).
• dbt com 12 modelos de transformação documentados.
• Metabase com 3 dashboards: operacional (site), gerencial (regional) e executivo (consolidado).
• Relatório semanal automático para Teams toda segunda 7h.

A planilha ainda existe, mas agora se preenche sozinha. O tempo do analista que a montava (4-6 horas semanais) passou a investigar perdas — onde agrega valor de verdade.

Checklist antes de pedir uma proposta

Antes de nos pedir (ou pedir a qualquer um) uma proposta de analítica, tenha claro:

• Quantos meses de dados limpos você tem hoje?
• Quem é o dono de negócio de cada dashboard que você pediria?
• Que decisão cada audiência vai tomar com esse dashboard?
• Quais são seus 5 KPIs mais importantes? (se a resposta for “todos”, não são KPIs)
• Precisa integrar com ERP/CRM existente? Qual?
• Há restrição de onde os dados podem viver (on-premise vs cloud)?
• Orçamento mensal aceitável de infra
• Quem manterá os dashboards depois de entregues?

Próximos passos

Se você tem telemetria capturada e sente que não está aproveitando, escreva para info@col0.com ou pelo WhatsApp. Na primeira reunião revisamos seu stack atual e dizemos honestamente se vale a pena montar um warehouse agora ou se convém esperar.

Mais detalhe do serviço em Analítica de dados industriais, e se seu próximo passo é preditivo, o post sobre IA aplicada a IoT industrial cobre os quatro padrões que realmente funcionam em produção.