Industrial data analytics: how to squeeze the 18 months of telemetry nobody is looking at

If your operation has been capturing telemetry for over a year — temperatures, levels, weights, consumption, machine events — you most likely have 18 months of data sitting in InfluxDB or PostgreSQL that nobody is looking at. In parallel, someone is still closing an Excel every Monday for the executive committee, and operations doesn’t talk to planning because each team has its own report.

That gap — between the telemetry you already have and the executive decision you need to make — is what we call industrial data analytics. It is not a “big data” project, and not a three-year corporate data lake. It is a practical, layered analytics layer built on top of what you already capture.

The three honest layers

The most common trap is mixing everything into a single “all-in-one” dashboard. It doesn’t work because audiences have different needs:

[ Sensors / PLCs / ERP ]
          ↓
[ Real time   ]  → Grafana → floor operator (seconds)
          ↓
[ Historical  ]  → Data warehouse / lakehouse → analyst (weeks)
          ↓
[ Executive   ]  → Power BI / Metabase → committee (month/quarter)

Each layer lives separately but talks to the others. The Monday executive dashboard does not query the time-series directly — that would crash it. It queries the warehouse, which materializes every night with aggregated data.

Layer 1 — Real time (operations)

Grafana on top of InfluxDB or TimescaleDB. View per equipment, per line or per site. This is the one the 24/7 guard keeps open on a wall display. Refreshes every 30 seconds. Pushes alerts to Slack, WhatsApp or PagerDuty.

What it isn’t: an executive dashboard. Leadership doesn’t need to see live temperature series — they need a KPI.

Layer 2 — Historical consolidated (analysis)

The most underrated layer. This is where the data warehouse or lakehouse lives. To start, we almost always recommend PostgreSQL + TimescaleDB with dbt for transformations. Once volume crosses ~50-100 million rows per month, or you need to cross-reference ERP/CRM data, jump to BigQuery or Snowflake.

Practical rule: if your team is spending more than USD 800/month on heavy queries against the operational database, you already have a business case to move analysis to a separate warehouse.

Layer 3 — Executive (decision)

Power BI or Metabase on top of the already-transformed warehouse tables. KPIs per site, per line, per SKU, per month. This is where OEE, MTBF, cost-per-hour-of-downtime and per-site shrinkage live.

The difference vs Excel is that this layer is built once and updates itself. Nobody closes anything on Mondays.

Stack we use (with honest costs)

Component	Start with	When it grows
PLC/sensor ingest	MQTT + edge gateway	Kafka Connect / Airbyte
Operational time-series	InfluxDB or TimescaleDB	InfluxDB Cloud / Timescale Cloud
Analytical warehouse	PostgreSQL + dbt	BigQuery / Snowflake
Transformation	dbt	dbt + Airflow
Operational dashboard	Grafana	Grafana Enterprise
Executive dashboard	Metabase (open source)	Power BI
Orchestration	cron + scripts	Apache Airflow / Prefect

The left column costs less than USD 200/month in infra and supports mid-sized plants. The right column starts around USD 1,500/month but supports multi-site setups and high volumes.

What dashboard each sector asks for

Sector	Typical executive KPIs
Manufacturing	OEE per line, scrap rate, changeover time, schedule attainment
Data center	Uptime per room, capacity utilization, HVAC MTBF, PUE consumption
Energy / Utilities	Technical vs non-technical losses, demand vs generation, events per substation
Logistics	Cost per km, consumption per route, container shrinkage, on-time delivery
Oil & Gas	Tank inventory, fueling-to-sale reconciliation, spills avoided
Cold chain	% time in range, breaks per site, time-to-target-temp
Agribusiness	Yield per plot, cost per hectare, environmental anomalies

Each of these KPIs comes from crossing the telemetry you already capture with data from your ERP or management system. It is not a new instrumentation project — it is squeezing what you already have.

Common mistakes (and how to avoid them)

1. Starting with the warehouse before reliable telemetry exists. If sensors return null 20% of the time, the warehouse will multiply the garbage. Stabilize capture first, consolidate second.
2. Mixing real time and history in the same dashboard. Slow queries follow, and the operator doesn’t know what to look at. Separate them.
3. Dashboards with no owner. A dashboard with no business owner goes stale in 6 weeks. Every dashboard needs a business owner and a technical owner.
4. Copying the executive Excel into Power BI without rethinking. If the Excel was already wrong, the Power BI will be wrong in nicer colors. Use the migration to rethink which decision each KPI supports.
5. Confusing BI with observability. Grafana is great for both but the mindset is different. Observability asks “what is happening now”; BI asks “what happened this month and why”.
6. Not documenting transformation logic. Three months later, if no one knows how OEE is calculated, you don’t have a KPI — you have an opinion. dbt handles this well.

When to graduate to AI

With six months or more of clean, consistent data in the warehouse, you have the raw material to start talking about predictive. Before that, models will learn noise instead of signal.

Natural bridges are:

• Forecasting of demand, consumption or generation → classic models (Prophet, ARIMA) usually suffice.
• Anomaly detection over time series → isolation forest or a simple autoencoder.
• Computer vision over existing CCTV → if cameras are already deployed, no new hardware needed.

We cover this in detail in the next post: AI applied to industrial IoT.

And if your site is rural and you’re concerned about pushing that much data to the cloud, there is an exit: edge inference over multi-Starlink connectivity processes locally and only uploads the important events.

Real case: from Excel to live OEE

The client from the cold chain case came in with 18 months of InfluxDB and an executive Excel that was closed every Monday. In 6 weeks we delivered:

• TimescaleDB consolidating 4 sites (previously siloed).
• dbt with 12 documented transformation models.
• Metabase with 3 dashboards: operational (per site), managerial (regional) and executive (consolidated).
• Automatic weekly report to Teams every Monday 7am.

The Excel still exists, but now it fills itself. The analyst’s time that used to build it (4-6 hours weekly) now investigates shrinkage — where it actually adds value.

Checklist before requesting a proposal

Before asking us (or anyone) for an analytics proposal, have these clear:

• How many months of clean data do you have today?
• Who is the business owner of each dashboard you would request?
• What decision will each audience make with that dashboard?
• What are your 5 most important KPIs? (if the answer is “all”, they aren’t KPIs)
• Need to integrate with existing ERP/CRM? Which one?
• Any constraints on where data can live (on-premise vs cloud)?
• Acceptable monthly infra budget
• Who will maintain the dashboards once delivered?

What’s next

If you have telemetry already captured and feel you’re not squeezing it, write to info@col0.com or via WhatsApp. In the first meeting we review your stack and tell you honestly whether it’s worth building a warehouse now or whether you should wait.

More service detail at Industrial data analytics, and if your next step is predictive, the post on AI applied to industrial IoT covers the four patterns that actually work in production.