Operators and managers generally should share the same underlying ISO 22400 KPIs, but not the same views of those KPIs.
Using a common KPI vocabulary (e.g., OEE, availability, performance, quality rate, NPT-related metrics) reduces arguments about definitions and supports traceability. However, what each role sees and uses in daily work should be tailored to decision rights, time horizon, and system maturity.
Where they should be the same
- Definitions and formulas: The KPI definition, calculation logic, and data sources should be common across roles and systems (MES, SCADA, historian, BI tools). If management reports show OEE that cannot be reproduced from line views, your data model and validation are at risk.
- Primary KPI set: Core ISO 22400 KPIs used for plant and line performance (e.g., OEE, utilization, order lead time, scrap / rework) should be the same family of metrics for operators, supervisors, and managers. Otherwise, you encourage local KPIs that are hard to maintain and audit.
- Time alignment: Shift, day, and batch boundaries should be consistent so that a manager’s daily report can be traced back to the operator’s shift data. This matters for regulated investigations and root cause analysis.
- Data provenance: Both views should rely on traceable, version-controlled calculation rules. Any change to how a KPI is computed must go through change control and be visible to all affected roles.
Where they should be different
- Granularity:
- Operators: Need near-real-time, machine- or cell-level KPIs, by job, batch, or short time buckets (e.g., 15 minutes). Focus is on immediate actionability: which constraint, which alarm, which order.
- Managers: Need aggregated KPIs by shift, line, area, product family, or plant. Focus is on trends, constraints across assets, and tradeoffs with cost, delivery, and quality.
- Context and detail:
- Operators: Need clear, simple signals tied to standard work and escalation paths. E.g., “performance below X% for Y minutes” with specific next actions, not full Pareto breakdowns of the last quarter.
- Managers: Need drill-down across lines, products, and time, plus integration with labor, maintenance, and quality data. This often requires BI tools or MES analytics, not just HMI dashboards.
- Time horizon:
- Operators: Primarily care about the current and just-finished shift, plus a short look-back for handovers.
- Managers: Care about weekly, monthly, and quarterly trends, variance against budget, and capability across assets and suppliers.
- Volume of metrics:
- Operators: A small, curated set of KPIs with clear thresholds. Too many on-screen metrics reduce focus and increase error risk.
- Managers: A broader KPI set for capacity, cost, quality, and delivery, provided it is governed and validated. They should still prioritize a concise primary dashboard.
Dependencies and constraints in real plants
What you can reasonably expose to each role depends heavily on your current systems and data quality.
- Data quality & integration: In brownfield environments with multiple MES/SCADA/ERP instances, it may be unsafe to expose highly granular real-time KPIs to operators if feeds are unreliable or not validated. In that case, start with a smaller, validated subset and expand carefully.
- Validation and change control: In regulated plants, any KPI used for operational decisions that could impact quality, safety, or compliance needs documented calculation logic, test evidence, and change control. Operator-facing KPIs often have more direct influence on product realization, so changes to those displays may carry higher validation burden.
- System coexistence: You may have multiple KPI pipelines: local dashboards on HMIs, an MES reporting module, and a corporate BI layer. For consistency, either:
- Drive both operator and manager views from a common, validated KPI service or data layer, or
- Document and control any known differences, and avoid using unaligned metrics for formal reviews or investigations.
- Legacy constraints: Many legacy HMIs cannot easily show richer ISO 22400 views without significant requalification and downtime. In these cases, it is common to keep operator views simple and stable, while managers see more evolved ISO 22400-aligned dashboards in separate tools. What matters is documented mapping between the two.
Risks of identical views for all roles
- Cognitive overload at the line: If operators see the same multi-page dashboards built for management reviews, they may struggle to identify what needs action now, which undermines standard work.
- Conflicting incentives: Manager-level KPIs often emphasize throughput and cost. If the same KPIs drive operator behavior without proper guardrails, you can get local optimization at the expense of quality or change adherence.
- Misinterpretation and blame: Highly aggregated KPIs (e.g., monthly OEE by plant) are not actionable for an operator. Showing them without context can increase frustration and blame without offering a way to improve.
Practical design approach
- Agree on the canonical ISO 22400 KPIs and formulas at the enterprise or plant level, and document them under change control.
- Map KPIs to decisions by role: For each role (operator, team lead, area manager, plant manager), specify which KPIs they use, what decisions they make with them, and within what time horizon.
- Start from operator use cases: Define a minimal, stable set of KPIs that directly supports standard work, escalation, and defect prevention. Validate these displays thoroughly.
- Layer management views on top: Build aggregate and trend views over the same KPI definitions. Integrate data from ERP, QMS, and maintenance systems carefully, and document any additional calculations.
- Control and version KPI changes: Treat KPI definitions, thresholds, and dashboards as configuration items. Changes should go through impact analysis, including effects on training, work instructions, and historical comparability.
In summary, operators and managers should use a shared, ISO 22400-aligned KPI foundation, but with role-specific, validated views. Identical dashboards for all roles are usually a sign of immature design and create risk in regulated, long-lifecycle environments.
