Real-time KPI tracking & Data visualisation with custom dashboards

Site-level KPI tracking tells you how a location is performing overall. It does not tell you which specific machine, line, or piece of equipment is driving that performance. For operations where a small number of assets account for a disproportionate share of downtime or quality issues, site-level aggregation can hide exactly the detail that matters most.  

Asset-level KPI and RAG configuration allows performance to be tracked down to the individual machine or line, with its own targets, its own colour-coded status, and its own drill-down history. This is particularly relevant for maintenance and reliability tracking, where a site-level OEE figure might look acceptable while one asset is quietly underperforming and dragging down the average. Configuring KPIs at asset level surfaces that underperformance directly rather than letting it get absorbed into a broader number that looks fine on the surface.

When each department calculates the same type of KPI slightly differently, comparing performance across the organisation becomes an exercise in reconciling definitions before any actual comparison can happen. One department may calculate downtime as scheduled stoppage time excluded, another may not. The resulting numbers look comparable but are not. 

Custom formulas configured once at the KPI definition level and applied automatically across every instance of that KPI remove that inconsistency. The calculation logic is defined centrally, and every department, site, or asset using that KPI produces a number using the same underlying formula. This does not prevent departments from having departments from having different KPIs suited to their specific context, but it ensures that where the same KPI is being tracked in multiple places, the numbers are genuinely comparable rather than superficially similar.

A dashboard designed for detailed analysis, with drill-down menus, filters, and configuration options, is not the right interface for a screen mounted on a production floor for passive viewing. Operations walking past need a clear, readable status view, not an interface built for someone actively investigating a deviation. 

Display-only mode strips the dashboard down to what is needed for a projection or wall-mounted screen: the KPI status, the trend, and the RAG indicator, without the interactive elements that a detailed review would require. This also reduces the risk of a screen accidentally being used to change a configuration or filter setting simply because it was left accessible in a public area. The same underlying data can be shown in the format that fits the context, whether that is a manager conducting a deep analysis at a desk or a full team viewing a simplified status board during a shift briefing. 

Not everyone who needs to see a KPI should be able to change its target, its formula, or its underlying data. Finance-related KPIs in particular require tighter control than general operational metrics, since an unauthorised change to a financial target or calculation has different consequences than an incorrect production figure. 

Configuring access so that designated users can enter or modify data while others have view-only rights protects the integrity of the KPI without restricting visibility. Derived KPIs, which are calculated from other metrics rather than entered directly, can be restricted to management-level across where the underlying formula needs tighter control. This layered approach means the right people can act on the data while the data itself is protected from unintended or unauthorised changes.

A KPI without a named owner is everyone’s responsibility, which in practice means it is often no one’s. When a metric underperforms and the review meeting asks who is addressing it, the absence of a clear owner turns the conversation into a discussion about who should be responsible rather than a review of what is being done. 

Assigning ownership to a specific individual at the point a KPI is configured removes that ambiguity before it becomes a recurring problem. The dashboard shows not just the metric and its status, but who is accountable for it. This also supports more targeted escalation. When a KPI is flagged as at risk, the notification goes to the person actually responsible for it rather than to a general distribution list that may not include someone positioned to act.

A KPI dashboard is only as useful as the operator’s ability to read and act on what is shows. For global manufacturing organisations where the workforce at one site may not share a primary language with the team that configured the system, an English-only interface creates a barrier that has nothing to do with the quality of the KPI data itself.  

Multi-language support means the same dashboard, the same KPI definitions, and the same underlying data can be presented in the language relevant to each site’s workforce. This matters for adoption specifically. A well-designed KPI system that operators cannot comfortably read will be used reluctantly or not at all, regardless of how good the underlying data and analysis capability is. Language support removes that adoption barrier without requiring separate configurations or duplicate systems for different regions.