How many KPIs should be global versus local?

There is no universal number, but the usual answer is: keep the global set small and the local set purposeful.

For most regulated manufacturing environments, a practical pattern is 5 to 12 global KPIs that are defined consistently across sites, plus a larger set of local KPIs owned by plants, lines, cells, or functions. The exact split depends on process similarity, data quality, governance discipline, and whether sites are actually comparable.

What should be global

Global KPIs should be limited to measures that meet all of these tests:

• Leadership needs them for cross-site decisions, not just reporting.
• The definition can be controlled consistently across plants.
• The underlying data is available with acceptable quality and timing.
• The metric can survive normal differences in routing, product mix, batch size, maintenance strategy, and quality workflows.

Typical candidates include a small set around delivery, quality, schedule adherence, inventory, capacity, or cost of poor quality, but only if the calculation logic is actually harmonized. If one site books rework inside standard routing and another books it as a separate event, the same KPI can mean different things.

What should stay local

Local KPIs should capture what operators, supervisors, engineering, and quality teams can actually act on day to day. These often include bottleneck-specific losses, queue time between process steps, first-pass behavior by product family, inspection backlog, tooling availability, training coverage, or specific sources of scrap and rework.

These measures are often more useful operationally than enterprise dashboards because they reflect local constraints. A site building stable repeat assemblies does not need the same local metrics as a high-mix repair operation or a tightly constrained outside-processing flow.

Why not standardize everything

Because full standardization usually breaks on operating reality.

In brownfield environments, plants often run mixed MES, ERP, QMS, historian, spreadsheet, and manual log processes. They may also differ in work definitions, shift calendars, routing granularity, labor booking, and nonconformance handling. Forcing one enterprise KPI model across all sites without fixing those differences usually creates three problems:

• Metrics look comparable when they are not.
• Sites spend time arguing definitions instead of improving performance.
• Teams create shadow reporting outside controlled systems.

That is why a layered model is usually safer than an all-global model.

A practical operating model

A common structure is:

• Tier 1 global: a small enterprise scorecard used for portfolio decisions and executive review.
• Tier 2 functional/global-local hybrid: common categories with limited local parameterization, such as quality loss, schedule attainment, or material availability.
• Tier 3 local: plant, line, cell, or program KPIs tied to actual constraints and daily management.

This approach preserves comparability where it matters while allowing sites to manage the process they actually run.

What ratio is reasonable

If you need a rule of thumb, many organizations are better off with roughly 20 to 30 percent global and 70 to 80 percent local by count. But do not treat that as a target. Some networks need fewer global KPIs because products and processes vary too much. Others can support more global KPIs if they have strong master data, common routing logic, disciplined change control, and validated system integration.

The real question is not the count. It is whether each KPI has a clear owner, stable definition, trusted source, and a decision that depends on it.

Common failure modes

• Too many global KPIs, which turns review meetings into dashboard maintenance.
• Global KPIs defined centrally but calculated differently in each plant.
• Local KPIs with no link to business outcomes, which creates optimization in the wrong direction.
• Metrics introduced before data readiness, causing manual workarounds and low trust.
• Replacing existing reporting too aggressively, which is risky in validated or heavily controlled environments.

That last point matters. Full replacement strategies often fail when legacy reporting is tied into qualified processes, audit evidence, or long-established operational routines. Coexistence is usually more realistic: stabilize a small canonical KPI layer first, map source systems carefully, validate calculations where required, and retire old reports gradually under change control.

Bottom line

Use as few global KPIs as you can govern well, and as many local KPIs as teams need to run the process responsibly. If a KPI cannot be defined consistently across sites, it should probably not be global.