What Is a KPI Dashboard?

Back to Blog

What Goes on an Operations KPI Dashboard

A good dashboard shows a curated few metrics, not everything measurable. In oil and gas operations these often include production volume against target, run time and downtime by well or site, average and peak alarm rates, equipment availability, and exception counts such as tanks approaching high level or sites offline. Each KPI is usually derived from many underlying SCADA tags - production, for instance, is aggregated flow across dozens of meters.

Design matters as much as content. Effective dashboards use consistent color coding, show each metric against its target or a threshold, and support drill-down so a red tile can be opened to reveal which site or asset is dragging the number. The discipline is restraint: a dashboard crowded with gauges becomes as unreadable as the raw data it was meant to replace.

How KPI Dashboards Fit the SCADA Stack

Dashboards sit above the real-time control layer. The SCADA system collects and historizes data from the field; the dashboard reads that data - often from the historian for anything time-averaged - and computes rolled-up indicators. Because they summarize rather than control, dashboards are frequently the view given to supervisors, managers, and executives who need situational awareness without operating the process.

Cloud-native SCADA makes these dashboards reachable from any browser, so a supervisor can check overnight production or the current alarm rate across every remote site from a phone. Merobix collects field data over protocols like Modbus, DNP3, and MQTT and historizes it, which is the data foundation a KPI dashboard is built on - the indicators are only as trustworthy as the underlying telemetry feeding them.

From Raw Tags to a Trusted Number: A Worked Example

Take runtime, the most quoted number in field operations. Symbolically it is simple: if a well's run-status tag accumulates R hours of running time in a reporting period of P hours, runtime is R divided by P, expressed as a percentage. The engineering is in the edge cases. If the site's communications were down for O of those hours, the dashboard has to decide whether those hours count as downtime, count as run time carried at last-known state, or are excluded so the period becomes P minus O. Each choice yields a different number from identical field data, and each can be defended - what matters is that the choice is made once, written down, and applied everywhere.

Production attainment works the same way: actual volume V over target volume T, with the same buried decisions. Is V the raw totalizer difference, or the value after a meter freeze was detected and back-filled? Does T prorate when a well is shut in for planned work? Does a partial day at the start of the month count fully or fractionally? A dashboard that cannot answer those questions in writing will eventually show a number someone disproves in a meeting, and trust, once lost, is expensive to rebuild.

How Dashboards Quietly Lie

Most dashboard failures are not blank tiles - a blank tile gets fixed the same morning. The dangerous failures are the quiet ones, where the tile keeps rendering a plausible number from bad inputs:

KPI	Usual source	Quiet failure to watch
Runtime / availability	Run-status tags totalized over the period	Offline sites silently dropping out of the average, which raises the fleet number
Production vs target	Flow totalizers rolled up across meters	Counter rollover, or a frozen meter feeding yesterday's value forward
Alarm rate	Alarm and event journal	One chattering point inflating the count, or shelved alarms hiding real load
Sites online	Communication status per site	Status held at last-good value so a dead site still shows green

Two more classics deserve their own mention. Time boundaries: a dashboard that rolls the day at midnight local time while measurement rolls at the contract gas day boundary will disagree with accounting forever, on every single day. And unit mixing: a rollup that sums meters configured in different units produces a number that looks precise and means nothing. Both are configuration decisions, not software defects, which is exactly why they survive so long.

Ownership: Every Number Needs a Name Beside It

A KPI without an owner decays. Someone has to own each metric's definition - the formula, the source tags, the exclusions, the time basis - and keep a short definition sheet anyone can read when the number is challenged. The sheet does not need to be long - half a page per KPI is plenty - but it must exist before the number appears on a screen anyone uses. When the calculation changes, the change is dated and noted, because a KPI whose history silently mixes two definitions cannot be trended honestly.

Ownership also means reconciliation. Operational rollups computed from historized telemetry will not exactly match the validated volumes produced by measurement and accounting, for good reasons - the difference between a historian and a database hints at how differently the two worlds treat data. The fix is not to force them equal but to reconcile on a schedule, explain the gap, and state on the dashboard which basis each tile uses.

Frequently Asked Questions