This article explains how to build an ISO 22400–aligned KPI governance framework that is practical, lightweight, and transparent. The focus is on organizational practices (roles, processes, and documentation), not on any specific technology or software stack.
Why KPI Governance Matters in Multi-Site Manufacturing
As plants digitize and more stakeholders gain access to performance dashboards, the number of metrics can explode. Without governance, the same label may mean different things in different places, and seemingly similar metrics may be calculated differently.
The risks of uncontrolled KPI proliferation
- Inconsistent definitions: One site measures “availability” including setup time; another excludes it. Both report a single percentage under the same name.
- Duplicated metrics: Slightly different formulas are introduced for similar KPIs, multiplying dashboards without improving insight.
- Hidden assumptions: Local spreadsheets and reports embed undocumented business rules that nobody else can see or audit.
- Integration overhead: IT teams must constantly translate between plant-specific definitions when building group reports or integrating new systems.
Impact on decision quality and trust in numbers
When people discover that two plants use different definitions for supposedly identical KPIs, trust erodes quickly. Common symptoms include:
- Management running parallel analyses to “verify” reported performance.
- Endless debates over which numbers are correct instead of what actions to take.
- Plants resisting corporate dashboards because they do not recognize the definitions.
A governance framework does not automatically improve performance, but it does make performance information reliable enough to support decisions.
How ISO 22400 provides a stable vocabulary
ISO 22400 offers a neutral, standardized language for manufacturing operations KPIs. It defines concepts such as availability, utilization, equipment states, time categories, and order-related performance in a technology-agnostic way.
By aligning governance with the ISO 22400 manufacturing KPI definition framework, organizations can:
- Start from published, consensus-based definitions instead of inventing everything from scratch.
- Make data integration easier between MES, ERP, historians, and reporting tools.
- Clarify which KPIs are standardized and which are organization-specific.
Defining Governance Roles and Responsibilities
Clear ownership is the foundation of KPI governance. Every KPI should have someone who is accountable for its definition, and a defined group that can propose changes.
Central KPI owners vs. local process experts
A practical pattern for multi-site manufacturers is to separate central ownership from local stewardship:
- Central KPI owners (often in an operations excellence, manufacturing engineering, or business analytics function) are accountable for:
- Maintaining the canonical definition aligned with ISO 22400 where applicable.
- Approving or rejecting change requests.
- Ensuring documentation stays complete and up to date.
- Coordinating across sites when a definition change has broad impact.
- Local process experts (plant engineers, production supervisors, maintenance leads) act as stewards who:
- Validate whether the KPI is meaningful and applicable locally.
- Identify issues with data availability or interpretation on the shop floor.
- Propose refinements or additional indicators to capture local realities.
This split keeps definitions coherent at the group level while still grounding them in operational reality.
Involving IT, operations, and finance
ISO 22400 KPIs touch multiple functions. A robust governance model usually involves three perspectives:
- Operations: Ensure that the KPI reflects how production, maintenance, and quality are actually managed day to day.
- IT / data engineering: Confirm that required data exists, can be collected reliably, and can be processed at the needed latency and granularity.
- Finance / controlling: Align operational KPI definitions with how performance is reported at higher levels without confusing operational indicators with financial results.
Many organizations formalize this collaboration in a cross-functional KPI steering group or data governance council that meets regularly to review requests and issues.
Decision rights for adding or changing KPIs
To avoid ad-hoc changes, define explicit decision rights:
- Who can propose: Typically any plant or function can raise a request for a new KPI or a change in definition.
- Who can recommend: A working group of subject-matter experts assesses the proposal, its ISO 22400 alignment, and technical feasibility.
- Who can decide: Central KPI owners or a governance board approve, defer, or reject changes, considering network-wide impact.
Documenting these rights reduces friction and ensures that no single site can unilaterally redefine a shared KPI.
Documenting KPIs Using ISO 22400 Concepts
Without structured documentation, governance becomes informal and dependent on tribal knowledge. ISO 22400 suggests a rich set of attributes that can be reused in your internal KPI catalog.
Using standardized attributes and terminology
For each KPI, capture a minimum set of attributes, reusing ISO 22400 concepts where they apply:
- Name: A unique label, ideally reflecting ISO 22400 terminology.
- Conceptual definition: A plain-language explanation of what the KPI measures, not just its formula.
- Scope / object of measurement: Work unit, line, area, plant, or order, aligned with the standard’s hierarchy.
- Domain: Production, quality, maintenance, inventory, or energy.
- Time behavior: Whether it is real-time, per shift, daily, weekly, etc.
- Underlying states and quantities: Which equipment states, time buckets, and material quantities feed into the KPI.
- Unit of measure and direction: Percentage, hours, units produced, with a clear statement of whether “more is better” or “less is better.”
- ISO 22400 linkage: References to the standardized concept (for example, “Aligned with ISO 22400 availability indicator”).
- Data source: Systems or sensors that provide the input data.
- Owner and stakeholders: Who is accountable for the definition and who uses it.
Clarify the operational risk
When the work behind KPI Governance with ISO 22400 affects quality, delivery, or compliance, teams need one place to connect evidence, decisions, and shop-floor follow-through.
Creating a centralized KPI catalog or dictionary
A centralized KPI catalog (sometimes called a KPI dictionary or data catalog entry for KPIs) makes these definitions discoverable and auditable. It may be implemented as:
- A specialized data catalog tool.
- An internal web portal with search and filters.
- A governed spreadsheet or database with controlled access.
Key success factors include:
- Assigning responsibility to keep entries current whenever dashboards or data models change.
- Ensuring that business users can easily navigate by plant, domain, or role.
- Linking catalog entries to report and dashboard metadata so that users can jump from a chart to its definition.
Marking which KPIs are ISO 22400-based
Not every KPI will or should be ISO 22400-based. To avoid confusion:
- Tag ISO 22400-aligned KPIs explicitly in the catalog (for example, a boolean flag or a specific category).
- Record any deviations from the standard definition, such as additional filters or modified scope.
- Use consistent naming conventions so that standardized KPIs are easy to recognize in reports.
This clarity helps teams distinguish between standardized, comparable KPIs and locally defined indicators designed for specialized needs.
Change Management for KPI Definitions
Once KPIs become embedded in reports, incentives, and supplier contracts, changing a definition can have significant consequences. ISO 22400 provides a stable foundation, but your own definitions will still evolve as operations change.
Assessing impact of KPI changes
Before modifying a KPI definition, governance should consider:
- Systems affected: Which dashboards, reports, alerts, and integrations consume this KPI?
- Stakeholders impacted: Which plants, teams, and external partners use it in their decision-making?
- Historical comparability: Will the change break trend analysis or contractual baselines?
- Standard alignment: Does the proposed change move the KPI closer to or further from ISO 22400 concepts?
Simple change templates or checklists make this assessment repeatable and auditable.
Versioning and communication practices
To keep trust in KPIs, treat definition changes like software releases:
- Version numbers: Assign a version to each KPI definition; increment it whenever the meaning changes, not just the visualization.
- Effective dates: Record when the new version takes effect, so data can be interpreted correctly over time.
- Change logs: Maintain a concise history explaining why each change was made and who approved it.
- Communication plans: Inform affected users in advance, including what will change, why, and how to interpret trends across the change.
Managing coexistence during transitions
In some cases, the old and new definitions must coexist for a period. Common strategies include:
- Dual reporting: Show both the legacy KPI and the new one on the same dashboard, clearly labeled, for a defined transition period.
- Back-calculation where feasible: If raw data allows, compute the new definition for past periods to maintain continuous trend lines, while documenting that the series was recalculated.
- Cutover points in reports: Mark the date when the definition changed on historical charts.
The goal is transparency: users should never be surprised by unexplained jumps in KPI values.
Embedding Governance into Tools and Workflows
Governance works best when it is built into everyday tools and processes instead of relying on manual policing. While ISO 22400 is technology-agnostic, its concepts can be enforced through configuration and automation.
Using platforms like an ISO 22400 KPI definition framework to enforce definitions
If you use a centralized platform for manufacturing performance reporting or a dedicated KPI management tool, you can configure it around ISO 22400 concepts:
- Define canonical formulas and scopes aligned with ISO 22400 in a single place.
- Expose standardized KPIs as reusable building blocks for dashboards and plants.
- Integrate the platform with your KPI catalog so that users can click through from a chart to its official definition.
Roles-based access to KPI configuration
Roles and permissions in reporting and analytics tools should reflect governance rules:
- Configuration roles: Only designated owners or administrators can edit standardized KPI definitions.
- Local extension roles: Sites can create plant-specific indicators, but must label them clearly and cannot overwrite global definitions.
- Viewer roles: Most users consume KPIs but cannot change underlying definitions.
This division enables local flexibility without sacrificing global consistency.
Automated checks to prevent duplicate or conflicting KPIs
Tools can support governance by detecting issues early:
- Name uniqueness checks: Prevent new KPIs from using names already assigned to existing indicators.
- Similarity checks: Flag definitions that are nearly identical to existing KPIs, prompting consolidation.
- Metadata completeness rules: Require key attributes (unit, owner, ISO 22400 alignment flag) before a KPI can be published.
- Approval workflows: Route new or changed KPI definitions for review before they appear in production dashboards.
Connect decisions to execution
Connect981 helps turn this kind of operational detail into traceable action, so the context behind each decision does not get lost.
Measuring the Success of KPI Governance
Governance itself should be monitored. While ISO 22400 defines operational KPIs, you can create a small set of governance health indicators to see whether your KPI management practices are working.
Indicators of improved comparability and trust
Signs that governance is effective include:
- Reduction in ad-hoc metrics: Fewer locally defined KPIs that duplicate or conflict with group standards.
- Stable definitions: Core KPIs change infrequently and, when they do, changes are properly documented.
- Fewer disputes over numbers: Less time spent reconciling reports across sites and more time spent on root-cause analysis and improvement ideas.
- Simpler system integration: New plants or systems can be onboarded using existing KPI definitions with minimal translation work.
Feedback loops from plant teams and management
Governance should be a living process, not a one-time project. To keep it relevant:
- Solicit regular feedback from plants on whether KPI definitions fit real-world operations.
- Schedule periodic reviews of the KPI catalog to retire unused indicators and refine ambiguous ones.
- Track issues raised through support channels or data-quality tickets that relate to KPI meaning or interpretation.
When feedback results in visible improvements, engagement with governance processes tends to increase.
Continuously evolving governance as operations change
As manufacturing strategies, products, and technologies evolve, so will your KPIs. ISO 22400 provides a durable backbone, but your governance model should accommodate:
- New domains (for example, energy efficiency or advanced traceability) that require additional indicators beyond the standard.
- New data sources such as IoT sensors or advanced analytics models that enrich existing KPIs.
- Organizational changes such as plant acquisitions or divestments that affect the set of shared KPIs.
The aim is not to freeze KPI definitions forever, but to manage change deliberately and transparently.
Putting It All Together
ISO 22400 does not prescribe how to govern KPIs, but it offers a clear conceptual foundation. By combining that foundation with practical governance practices — ownership, documentation, change control, and tool support — manufacturers can create a KPI environment that is both comparable across sites and adaptable to local realities.
A well-run governance framework will not, by itself, improve performance. What it does is ensure that leaders, engineers, and operators share a common understanding of the numbers they use to steer the business. That shared understanding is a prerequisite for meaningful, data-informed improvement across modern manufacturing networks.
For teams putting this topic into daily operation, ISO 22400 KPI governance, a connected execution platform, Connect981’s aerospace execution solutions help connect the concept to traceability, work-order reality, and audit-ready evidence.
This article is for aerospace operations, quality, and compliance teams who need to understand KPI Governance with ISO 22400: Roles, Rules, and Routines. It explains the practical question this topic answers in a manufacturing execution context.
The same operating model also depends on real aerospace execution examples, Connect981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.
For teams putting this topic into daily operation, ISO 22400 KPI governance help connect the concept to traceability, work-order reality, and audit-ready evidence.
Frequently asked questions
Use labeling that makes the link to ISO 22400 explicit and traceable, while still readable for operators and managers. In regulated, brownfield environments, the priority is clarity, consistency, and unambiguous mapping to the standard and to your validated configuration.
Use a consistent naming pattern
Pick a standard pattern and apply it on every dashboard, report, and export. Common workable options are:
- “ISO 22400 KPI <number>: <standard name>”
Example: “ISO 22400 KPI 1: Availability” - “ISO 22400-2 K<2-digit code> – <standard name>”
Example: “ISO 22400-2 K01 – Availability” - For OEE-related metrics:
“ISO 22400 K01 – Availability (OEE component)”
“ISO 22400 K02 – Performance (OEE component)”
“ISO 22400 K03 – Quality rate (OEE component)”
The key is that the label clearly states the standard and KPI code so it can be traced back to your requirements, configuration, and validation documentation.
Show definitions, units, and time basis
Labels alone are not enough in regulated environments. Make the KPI definition transparent at the point of use:
- Include units directly in the label or sublabel, for example: “ISO 22400 K01 – Availability [%]” or “ISO 22400 K09 – Production time [min]”.
- Indicate time basis where it affects interpretation, for example: “… (shift)”, “… (last 24h)”, “… (rolling 30 days)”.
- Expose the formula via a hover tooltip, info icon, or drill-down page. The visible label should match a controlled definition in a specification or data dictionary.
This makes it easier for engineers, quality, and auditors to validate that what the screen shows matches the approved definition.
Handle site-specific variants explicitly
Many plants cannot implement ISO 22400 definitions 1:1 because of legacy data models, partial integrations, or local business rules. If you must deviate:
- Use a variant label, for example: “ISO 22400 K01 – Availability (site variant)”.
- Document the difference in a controlled specification (for example, data dictionary, MES configuration spec, or dashboard design doc) and reference that in validation records.
- Avoid ambiguous renaming. Do not call a non-standard metric simply “OEE” or “Availability” without indicating it is a modified definition.
In mixed-vendor MES/SCADA/ERP stacks, different systems may compute similar KPIs differently. Make the system of origin or method visible where conflicts are likely, for example: “ISO 22400 K01 – Availability (MES)” vs “… (SCADA)”.
Align labels with your MES/ERP and procedures
To avoid confusion in brownfield environments:
- Align terminology across dashboards, MES screens, batch records, and SOPs. If MES uses “Equipment availability”, your dashboard label might be “ISO 22400 K01 – Equipment availability” to bridge both.
- Use a governed data dictionary or master KPI catalog that lists: ISO 22400 code, standard name, local display label, units, calculation method, and system(s) providing the data.
- Control changes via your existing change control process. A label change that alters the meaning, formula, or data source should be reviewed and, where applicable, revalidated.
Full replacement of existing KPI naming across legacy systems is often risky and resource-intensive due to the need to update SOPs, training, qualification evidence, and audit trails. In many plants, a pragmatic overlay approach is used: add ISO 22400 codes to labels and documentation while existing local terms remain visible.
Make drill-down and traceability available
Dashboards in regulated operations should let a knowledgeable user trace what a KPI number represents:
- Provide a details view where users can see the ISO 22400 code, full name, formula, aggregation rules, and exclusions (for example, which downtime categories are included).
- Link to controlled documents such as KPI specifications or functional requirements, instead of embedding long definitions directly on the chart.
- Ensure consistency across views. A label used on a line-level dashboard should match the label used in corporate performance summaries for the same KPI definition.
Practical labeling examples
Here are examples of clear labels that balance ISO fidelity and operator readability:
- “ISO 22400-2 K01 – Availability [% per shift]”
- “ISO 22400-2 K03 – Quality rate [% – site variant A]”
- “ISO 22400 K02 – Performance (OEE component) [%]”
- “ISO 22400 K09 – Production time [min, MES]”
- “ISO 22400 K13 – Scrap rate [% – includes rework]” (with the inclusion of rework defined in your KPI spec)
These patterns give enough information for experts to interpret and challenge the numbers, while remaining short enough for dashboards.
Implementation dependencies and caveats
Clear ISO 22400 labeling depends on:
- Configuration quality: You must know exactly how each KPI is computed in each system. If formulas differ or data is incomplete, labeling alone will not align behavior.
- Integration maturity: Incomplete equipment connectivity or partial downtime classification may force you to define and label KPIs as intermediate or provisional metrics.
- Validation state: In GxP or aerospace-grade contexts, any change to KPI calculations or their interpretation should be assessed for impact on validated processes and evidence packages.
Labeling ISO 22400 KPIs clearly is less about picking the “right” wording and more about ensuring that every label can be unambiguously traced to a controlled, standardized, and validated definition within your actual system landscape.
In an ISO 22400 program, no single function should unilaterally own KPI definitions. The most effective approach is a formal, cross functional governance group that is accountable for defining, approving, and changing KPI definitions, with clearly assigned roles inside that group.
Recommended ownership model
For regulated, brownfield environments, a practical split of responsibilities is:
In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.
- Executive sponsor (Operations or Plant leadership): Owns the overall KPI framework, priorities, and conflict resolution. Ensures KPIs support strategy, not just data availability.
- Process owners (Operations / Manufacturing Engineering / Maintenance): Own the operational meaning of each KPI (e.g., what counts as planned production time, what is valid downtime, how to treat changeovers or inspections). They drive usability and prevent definitions that are theoretically correct but operationally useless.
- Quality / QMS: Owns traceability, documentation, and change control of KPI definitions. They ensure that definitions, formulas, and data sources are version controlled, reviewed, and aligned with quality procedures and audit expectations.
- IT / OT / MES data stewards: Own the technical implementation of KPI definitions in MES, historians, data lakes, and reporting tools. They are responsible for data lineage, mapping to ISO 22400 structures, and ensuring that different systems calculate KPIs consistently.
- Finance / Controlling (where relevant): Validates that cost, efficiency, and utilization KPIs align with financial reporting and do not create conflicting “truths” between plant and corporate dashboards.
Why shared ownership is critical for ISO 22400
ISO 22400 provides standardized terminology and formula structures, but each plant still has to decide:
- How to classify and segment time (e.g., planned vs unplanned stops, changeovers, maintenance windows).
- Which equipment and value streams are in scope for each KPI.
- How to handle borderline cases (rework, test cycles, engineering trials, quality holds).
- How to align KPI definitions across MES, ERP, SCADA, and reporting tools.
If KPI ownership sits purely in IT, you risk technically consistent metrics that are operationally meaningless. If it sits purely in operations, you risk local optimizations, poor documentation, and divergence across sites. If it sits purely in quality, you may get good procedures but low adoption. A shared model with explicit governance responsibilities balances these risks.
Governance and change control expectations
In regulated and long lifecycle environments, KPI definition ownership must include structured governance, not just an informal committee. At minimum:
- Authoritative KPI catalog: A single, controlled list of ISO 22400 KPIs, including name, formula, inputs, exclusions, calculation level (machine, line, plant), and system of record.
- Formal approval workflow: Proposed new KPIs or definition changes are reviewed and approved by the governance group (operations, quality, IT/OT, and finance as needed), with documented rationale and impact.
- Version control and traceability: Each KPI definition has a version history that makes it clear when and why a change was made, which systems were impacted, and which periods are not comparable due to a definition change.
- Impact assessment and validation: Before changes go live, data stewards and process owners validate that the implementation matches the approved definition, and that reports, dashboards, and alerts behave as expected.
- Communication and training: Changes to KPI definitions are communicated to supervisors, engineers, and analysts so that performance trends are interpreted correctly.
Coexistence with existing systems in brownfield plants
In brownfield environments, KPI definition ownership is constrained by existing MES/SCADA, historians, ERP, and reporting tools, many of which embed their own KPI calculations. A realistic ownership approach acknowledges that:
- You often cannot replace all existing KPI logic in legacy systems without major validation, downtime, and requalification. Instead, you typically define a system of record for each KPI and document how other systems approximate or consume it.
- Different lines, plants, or vendors may use slightly different KPI formulas today. Ownership includes deciding whether to harmonize, and if so, over what time horizon and with what revalidation burden.
- Data integration and mapping efforts must be jointly owned by IT/OT and process owners so that ISO 22400 fields are populated correctly and consistently across interfaces.
- External reporting (to customers, regulators, or corporate) may already rely on specific definitions. Changing them can have audit and contractual implications that need quality and legal review.
Because full replacement of legacy KPI logic can be risky and expensive in regulated contexts, the governance group often prioritizes:
- Defining and documenting canonical ISO 22400-aligned KPIs first.
- Mapping current system outputs to those definitions, with clear notes where they differ.
- Gradually refactoring or consolidating KPI calculations as systems are upgraded or revalidated.
Practical steps to assign ownership
To establish ownership without reorganizing your entire structure:
- Appoint an ISO 22400 KPI program lead (often from operations excellence or manufacturing engineering) who coordinates the work but does not own definitions alone.
- Create a KPI governance charter that names the core group (operations, quality, IT/OT, finance) and spells out decision rights, approval workflows, and documentation expectations.
- Start with a small, critical set of KPIs (e.g., availability, performance, quality rate, OEE, NPT) and assign specific process owners and data stewards to each.
- Document the current state vs ISO 22400-aligned target state for each KPI, including where existing systems deviate.
- Integrate KPI definition changes into existing change control processes (e.g., IT change management and QMS document control), so modifications are tracked like any other controlled change.
In summary, KPI definitions in an ISO 22400 program should be owned by a cross functional governance group with clear accountability: operations for practical meaning, quality for traceability and change control, IT/OT for data integrity and implementation, and finance for alignment with business reporting. The exact org chart matters less than having explicit roles, documented decisions, and disciplined change management across your existing systems.
ISO 22400 KPI definitions should not sit with a single function. In regulated, long-lifecycle environments, they are best owned through a formal cross-functional governance model, with a clear operational steward.
Recommended ownership model
A practical pattern is:
In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.
- Cross-functional governance body as the owner of definitions
Typically a performance management council, data governance board, or similar forum with representation from:- Operations / Manufacturing engineering (how work is actually executed)
- Quality (traceability, auditability, and alignment with QMS)
- IT/OT / MES team (data sources, integration, system changes)
- Supply chain / Planning (where KPIs touch scheduling and materials)
- Finance / Controlling (cost-related KPIs and financial alignment)
This group owns the authoritative KPI catalog, including ISO 22400 mappings, calculation logic, and change control.
- Operations as day-to-day steward
Operations leadership (plant manager, value stream leader, or equivalent) should typically be the steward for production KPIs such as OEE and NPT: they rely on them for decisions and are accountable for results. They do not own the IT implementation in isolation, but they own how the KPI is used operationally. - IT/OT as technical custodian
IT/OT teams (often the MES/SCADA data owners) are responsible for implementing the agreed definitions in systems, guarding data lineage, and documenting interfaces. They should not change KPI logic unilaterally; they execute changes approved by the governance body.
Why single-function ownership usually fails
Common failure modes when one group “owns” ISO 22400 KPIs in isolation:
- IT-only ownership: KPIs are technically consistent but disconnected from how work is actually done. Plants bypass official dashboards and create shadow spreadsheets, breaking traceability.
- Operations-only ownership: Each plant tweaks definitions (e.g., what counts as planned vs unplanned downtime), destroying comparability across sites and complicating audits.
- Quality-only ownership: Definitions may be robust from a compliance standpoint but too slow to change or too narrow for real-time performance management.
ISO 22400 is a common language for manufacturing KPIs. In brownfield environments with mixed MES/ERP/PLM/QMS, no single function sees the full picture. A shared governance model is usually the only way to keep definitions stable, comparable, and auditable.
Key responsibilities to assign explicitly
Regardless of your exact org chart, make sure the following responsibilities are clearly assigned:
- Definition authority: Who approves a new KPI or a change to an existing one (e.g., OEE, availability, performance, quality rate) and ensures it stays consistent with ISO 22400 concepts where applicable.
- Data source and lineage ownership: Who documents and approves which systems and tags feed each KPI, how manual data entry is controlled, and how changes to those sources are validated.
- Calculation & configuration control: Who maintains the official calculation logic, handles versioning, and manages change requests in MES/BI/ERP. This should run under formal change control, not ad-hoc edits.
- Validation & reconciliation: Who signs off that KPI outputs match reality (e.g., cross-check OEE vs shift reports or maintenance logs) when systems, routing rules, or data integrations change.
- Access & usage rules: Who decides where KPIs are exposed (shop floor displays, management reports, supplier scorecards) and ensures that unofficial variants do not proliferate.
Working in brownfield, multi-system environments
In most regulated plants, you will have more than one system touching each KPI (MES, ERP, historians, manual logs). Full replacement with one “KPI system” is rarely realistic due to validation burden, downtime risk, and integration complexity. Instead:
- Keep one definition of each KPI, even if it is instantiated in multiple tools.
- Document for each KPI: system of record, system of display, and any site-specific exceptions that have been formally approved.
- Run changes through the same change control used for other validated systems; re-validate critical KPIs when integration or MES logic changes.
For regulated sectors, this approach supports traceable, consistent KPIs without assuming a greenfield stack or a single-vendor solution.