Dashboards should distinguish global from local KPIs by making three things explicit: what must be standardized, what is intentionally site-specific, and how each metric is governed.
In practice, global KPIs are enterprise measures used to compare performance, risk, or trend across plants, programs, or business units. Local KPIs are operational measures used to run a specific line, cell, area, shift, or site. They should not be mixed as if they are equally comparable.
What should be global
Make a KPI global only if all of the following are true:
-
The business question is the same across sites.
-
The calculation logic is stable and documented.
-
The underlying data sources are sufficiently consistent.
-
The units, time windows, inclusion rules, and exclusions are controlled.
-
There is a named owner for definition changes and exception handling.
Examples often include delivery performance, first pass yield, schedule adherence, inventory accuracy, or selected quality and capacity indicators. Even then, the metric may still need qualification notes if plants operate under different routings, product complexity, outsourcing models, or inspection strategies.
What should stay local
Keep a KPI local when it reflects a constraint, process design, or operating pattern that is not meaningfully comparable across the network. Examples can include queue aging at a specific bottleneck, rework loops unique to a product family, tooling changeover loss on one asset type, or technician certification coverage in a specialized area.
Local KPIs are not inferior. They are often more actionable. The mistake is treating them as enterprise scorecard metrics when their meaning depends on local routing logic, staffing models, machine capability, or data capture discipline.
How to show the distinction on the dashboard
-
Use separate sections or views for enterprise scorecard KPIs and site or area management KPIs.
-
Label each KPI with scope such as global, site, line, cell, or program.
-
Display the metric owner and definition version where practical.
-
Show calculation context, especially time basis, denominator, and exclusions.
-
Prevent rollups where the underlying local metrics are not semantically equivalent.
-
Provide drill-down from a global KPI into local drivers rather than blending them into one number.
A useful pattern is: executives see a small set of governed global KPIs, while site leaders see those same KPIs plus local driver metrics that explain movement and support action.
Governance matters more than graphic design
The distinction is mainly a governance issue, not a visualization issue. If one plant calculates on-time delivery from ERP promise date, another from customer commit date, and a third excludes partial shipments, a single global chart creates false precision. The dashboard may look consistent while the metric is not.
At minimum, global KPIs need controlled definitions, versioning, change control, and a process for handling site exceptions. Local KPIs need local ownership and review, but they should still be traceable to documented logic if they drive quality, release, or escalation decisions.
Brownfield reality
In mixed MES, ERP, PLM, QMS, and historian environments, global and local KPI boundaries often reflect system limitations as much as business intent. One site may have event-level machine and labor data, another may depend on manual entries, and a third may only have batch-level ERP transactions. That means some KPIs can be globally standardized only at a coarse level, while operationally useful local KPIs remain site-specific.
Trying to force full KPI uniformity too early often fails. In regulated, long-lifecycle environments, full replacement or hard standardization programs can stall under validation effort, downtime risk, qualification burden, and integration complexity. A more durable approach is to standardize a small governed enterprise layer first, then map local metrics beneath it with clear lineage and caveats.
Practical rule
If a KPI will be used for cross-site comparison, executive review, or formal target setting, treat it as global and govern it tightly. If it is primarily used to run local operations, diagnose constraints, or improve a specific process, keep it local and do not force comparability unless the data and process definitions actually support it.
The goal is not one dashboard with one truth for everything. The goal is a dashboard structure that distinguishes comparable enterprise signals from local operational signals without hiding the assumptions behind either.