How do we show both global and local KPIs in the same dashboard?

Yes, but only if you separate standardized enterprise metrics from locally useful operational metrics and govern how they relate.

The practical pattern is a layered dashboard:

• Global KPIs at the top, using one approved definition across plants, programs, or business units.
• Local KPIs underneath or behind drill-down views, showing site, line, cell, product-family, or shift-level performance in the context operators and supervisors actually manage.
• Explicit mapping between the two, so users can see whether a local measure feeds a global KPI, explains it, or exists only for local control.

If you do not govern that relationship, the dashboard becomes misleading. Many organizations say they have one KPI framework when they actually have multiple formulas, different data cutoffs, different exclusions, and inconsistent master data. In that case, putting global and local KPIs on the same screen creates apparent alignment without real comparability.

What has to be standardized

Not everything needs to be identical across sites. The items that usually do need standard control are:

• metric name and business definition
• formula and inclusion or exclusion rules
• time basis, refresh cadence, and reporting window
• source systems and system-of-record precedence
• unit of measure and normalization logic
• owner, approval workflow, and change control

Without that baseline, a global KPI is often just a roll-up of incompatible local numbers.

What can remain local

Local KPIs are still important because plants do not run the same process, asset mix, staffing model, product mix, or constraint profile. A site may need local measures for setup loss, queue age, first-pass inspection delay, rework load, tool availability, outside processing turnaround, or traveler completion lag. Those may be operationally critical even if they are not appropriate as enterprise KPIs.

The key is to label them clearly as local, define their scope, and avoid presenting them as cross-plant comparable unless they truly are.

Recommended dashboard structure

1. Start with enterprise KPIs that answer leadership questions consistently across the network.
2. Allow drill-down by site, program, line, product family, shift, or asset without changing the core definition of the enterprise KPI.
3. Add local KPIs in a separate section for the selected site or area.
4. Show lineage or metric metadata so users can inspect definitions, sources, and last refresh times.
5. Flag exceptions where a site cannot yet calculate the standard KPI due to missing data, legacy systems, or process variation.

This structure is usually more credible than trying to make one flat dashboard satisfy executives, plant leaders, and frontline supervisors equally well.

Brownfield reality

In mixed MES, ERP, PLM, QMS, historian, and spreadsheet environments, the main issue is rarely dashboard software. It is data semantics and integration debt.

Common failure modes include:

• the same KPI calculated in different systems with different logic
• site-specific spreadsheet adjustments outside audit trails
• local event codes that do not map cleanly to enterprise loss categories
• different production calendars, shifts, or batch boundaries
• missing context such as rework, holds, nonconformance status, or genealogy links
• master data conflicts for work centers, part numbers, routings, and organizational hierarchies

That is why full replacement is often the wrong first move in regulated, long-lifecycle environments. Replacing every local system just to force one KPI model usually runs into qualification burden, validation cost, downtime risk, and integration complexity. In many plants, a better path is coexistence: keep systems in place, define a canonical metric layer, map local data carefully, and tighten governance over time.

Tradeoffs to expect

There is no perfect design. You are balancing competing needs:

• Comparability versus local usefulness: the more standardized a KPI is, the less it may reflect local operational reality.
• Simplicity versus traceability: executives want clean rollups, but regulated operations often require users to inspect underlying records and exclusions.
• Speed versus control: fast dashboard rollout is possible, but trustworthy KPI harmonization takes data cleanup, ownership, and change control.
• Single source of truth versus multiple fit-for-purpose views: one semantic layer is desirable, but different roles still need different visualizations and tolerances.

If leadership insists on one dashboard, make sure that means one governed metric framework, not one screen that hides inconsistency.

Minimum governance model

At a minimum, assign:

• metric owners for each global KPI
• site owners for local KPI definitions and mappings
• approval and version control for formula changes
• documented exceptions for sites that are not yet aligned
• traceability from dashboard values back to source transactions or events where feasible

That last point matters in regulated operations. If a KPI drives management action, investigations, or audit evidence, users need confidence in where the number came from and what changed.

So the short answer is: yes, show both global and local KPIs in the same dashboard, but do it as a governed hierarchy, not as an unstructured mix of metrics.