The operating problem
Dashboards are easy to request because everyone can imagine a screen with red, amber and green indicators. The difficult questions come later: Which database field is authoritative? What does “late” mean? Are missing records zero or unknown? Who owns an exception? Can a manager drill into the events behind the total? If these questions are unresolved, the dashboard becomes another argument rather than a shared operating picture.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 07 Jul 2026 · Last reviewed 07 Jul 2026Begin with the meeting, not the chart library
The strongest starting point is a real shift, daily or weekly review. Record the questions people ask, the decisions they make, the reports they open and the disputes that delay action. A dashboard should remove the repeated effort required to reach those decisions.
- Name the decision associated with each KPI.
- Remove metrics that nobody acts on.
- Design priority and exception views before historical decoration.
Definitions must be operationally agreed
Words such as completed, available, downtime, backlog and on-time often have different meanings across departments. A formula can be technically consistent and still be rejected because it does not match the operating definition. Definitions should be documented with inclusions, exclusions and ownership.
- Write the calculation in business language before SQL.
- Version important definitions when policy changes.
- Show data period, refresh time and scope visibly.
Unknown is not zero
Missing device data, unsubmitted forms and failed imports should not silently become zero or normal. Zero is a valid measured value; unknown is a data-quality state. Dashboards that hide the difference create false confidence.
- Expose stale and incomplete data intervals.
- Separate no activity from no data.
- Route persistent data-quality failures to an owner.
Drill-down creates trust
Users trust a total when they can inspect the records behind it. A dashboard should allow movement from KPI to category, item and source record without requiring a developer to run a query. This also makes calculation defects and operational anomalies easier to identify.
- Preserve stable identifiers between summary and detail.
- Show exclusions and overrides where relevant.
- Allow export when users need independent reconciliation.
Live views and historical reports serve different jobs
A command centre highlights what requires attention now. Historical reporting explains patterns over a period. Combining both into one overloaded screen often weakens each. Current queues need freshness and action ownership; analytical reports need consistent periods, filters and reproducibility.
- Separate operational status from trend analysis.
- Optimise live views for exception response.
- Optimise historical views for comparison and reconciliation.
Measure whether visibility changed behaviour
A dashboard is not successful because it was opened. Measure whether meetings are shorter, exceptions are resolved sooner, manual report preparation falls and disputed figures decrease. Visibility creates value only when it improves the operating loop.
- Capture baseline report preparation time.
- Measure age and closure of visible exceptions.
- Track recurring disputes or manual corrections after launch.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The business cannot agree on definitions.
The dashboard is premature.
Run a data and KPI definition workshop first.
Data exists and reports are manually rebuilt each week.
A governed reporting layer may deliver quick value.
Automate trusted queries, filters and exports.
Managers need to see what is blocked right now.
A command-centre view is appropriate.
Design current status, ownership and drill-down around exceptions.
Source data has frequent gaps or corrections.
Data quality must be visible in the product.
Add freshness, completeness and exception indicators.
Evidence that the current approach is becoming risky.
- The dashboard specification lists charts but not decisions.
- Different departments calculate the same KPI differently.
- Missing data is silently displayed as zero.
- Users cannot inspect the records behind a total.
- A live operations screen is overloaded with every historical report.
What to clarify before commissioning work.
- List the recurring management questions and actions.
- Define every KPI in business language.
- Identify source systems and data ownership.
- Specify missing, stale and corrected data behaviour.
- Design drill-down from summary to source record.
- Measure reporting effort and decision delay before and after launch.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Should every KPI be real-time?
No. Refresh frequency should match the decision. Real-time infrastructure adds complexity when an hourly or daily update would support the same action.
Can a dashboard fix poor source data?
It can expose and route data-quality issues, but it cannot make unreliable records correct through visualisation alone.
What is the difference between a dashboard and a report?
A dashboard usually prioritises current status and exceptions. A report provides reproducible analysis over a defined period. Some systems need both, but they should be designed for their separate jobs.
How many metrics should appear on the main screen?
Only enough to support the primary operating decisions. Additional analysis should be available through drill-down or separate reports.