Connect981 – Content Dev

RSC Topic: Operational Performance Metrics (OEE, NPT, COPQ)

KPI definition, measurement logic, and financial impact modeling.

  • Custom KPI

    A custom KPI is a performance indicator that an organization defines and configures for its own specific objectives, instead of using only standard, pre-defined metrics such as OEE or throughput. It is typically implemented in reporting, MES, OT dashboards, or business intelligence tools to track performance against locally relevant goals.

    In industrial and regulated manufacturing environments, custom KPIs often combine data from production equipment, MES, quality systems, ERP, or maintenance systems. They are usually parameterized in a configuration layer, not hard-coded in software, so that operations, engineering, or quality teams can adjust definitions as processes and requirements change.

    Typical characteristics

    • Organization-specific definition: Based on the site, product family, process, or regulatory context, rather than a generic industry formula.
    • Explicit calculation logic: A clearly defined formula or rule set (for example, a weighted score of scrap, deviations, and rework hours).
    • Defined data sources: Input data fields and systems are specified, such as MES production records, LIMS results, or ERP order data.
    • Governed ownership: A responsible function (operations, quality, engineering, or finance) owns the definition, thresholds, and update process.
    • Configured in tools: Implemented in dashboards, reports, or KPI engines where users can filter by line, product, shift, or batch.

    Examples in manufacturing

    • A batch-release timeliness index that combines laboratory lead time, QA review duration, and documentation cycle time.
    • A supplier performance KPI that weights on-time delivery, incoming defect rate, and response time to nonconformances.
    • A line stability KPI calculated from unplanned stoppages, minor stops, and speed-loss events captured by OT systems.
    • A training effectiveness KPI linking operator qualification status to first-pass yield on a regulated process.

    Operational considerations

    • Traceability of definition: Documenting the formula, thresholds, and change history is important in regulated environments.
    • Data quality: Custom KPIs are sensitive to missing, delayed, or inconsistent source data from MES, ERP, historians, or QMS.
    • Alignment with standard metrics: Custom KPIs often supplement, not replace, standard measures such as OEE, NPT, or COPQ.
    • System integration: Calculation may require integration across OT data sources, MES, and enterprise reporting platforms.

    Common confusion

    • Custom KPI vs. standard KPI: A standard KPI uses widely accepted formulas (for example, OEE). A custom KPI is defined locally, even if it reuses some standard components.
    • Custom KPI vs. raw metric: A raw metric is a direct measurement (for example, “number of batches”). A custom KPI usually combines or normalizes multiple metrics into a single indicator.
    • Custom KPI vs. alert or rule: An alert is a system response (for example, a notification when a limit is exceeded). The custom KPI is the underlying measured value that may drive that alert.

  • Defect Rate

    Defect rate is a quality metric that expresses how often defects occur in a population of produced items, process outputs, or opportunities for error. It is usually represented as a percentage, ratio, or count per million, and is used to quantify the level of nonconformance in manufacturing and other industrial operations.

    What defect rate measures

    Defect rate commonly refers to one of two related concepts:

    • Unit-based defect rate: The proportion of units or batches that contain at least one defect. For example, 20 nonconforming units in a sample of 1,000 gives a defect rate of 2%.
    • Opportunity-based defect rate: The number of defects per defined opportunity (such as per feature, per component, or per process step). This is often expressed as defects per million opportunities (DPMO) in Six Sigma style analysis.

    In regulated or high-reliability manufacturing, the specific definition must be stated clearly, including whether reworkable defects, cosmetic defects, or only critical nonconformities are counted.

    How defect rate is calculated

    Common calculation forms include:

    • Defect rate by unit = (Number of defective units) / (Total units inspected)
    • Defect rate by defect count = (Total defects found) / (Total units inspected)
    • DPMO = (Total defects) / (Units inspected × opportunities per unit) × 1,000,000

    The chosen formula depends on the inspection strategy, regulatory expectations, and how quality data are recorded in MES, LIMS, QMS, or ERP systems.

    Role in manufacturing and regulated environments

    In industrial operations, defect rate is used to:

    • Monitor product and process quality over time.
    • Support release decisions for lots or batches, often with defined acceptance criteria.
    • Feed into cost of poor quality (COPQ) and yield calculations.
    • Trigger investigations, corrective and preventive actions (CAPA), and process improvements.
    • Provide evidence during audits that quality performance is being measured and managed.

    Defect rate can be captured at different levels, such as per machine, per production line, per shift, per supplier lot, or per product family. In integrated OT/IT environments, these data may come from automated inspection systems, manual quality checks, or a combination of both.

    What defect rate includes and excludes

    Defect rate typically includes any verified nonconformity detected within the defined inspection scope. It may cover:

    • Critical, major, and minor defects, where such categories are defined.
    • Defects found during in-process checks, final inspection, or incoming inspection.

    It generally excludes:

    • Events not tied to product quality, such as equipment downtime or schedule delays.
    • Process deviations that do not result in a product nonconformance, unless the site explicitly chooses to treat them as defects for reporting.

    Because inclusion rules vary by organization and standard, defect rate reporting usually relies on documented inspection procedures and data definitions.

    Common confusion

    • Defect rate vs. rejection rate: Rejection rate typically refers to units or lots that are not accepted for release. Defect rate can be higher than rejection rate, since some defects may be reworked or accepted under deviation.
    • Defect rate vs. failure rate: Failure rate is often used for reliability in use (field failures over time), while defect rate focuses on quality at production or inspection.
    • Defect rate vs. yield: Yield represents the proportion of acceptable output, while defect rate represents the proportion of nonconforming output. They are related but not interchangeable.

    Operational use in systems

    In integrated manufacturing environments, defect rate may appear as:

    • A KPI on MES or quality dashboards showing defects per line, product, or shift.
    • Reports generated from QMS or LIMS summarizing nonconformances by category.
    • Supplier quality metrics tracking defects found in incoming inspection.
    • Inputs to OEE and COPQ analyses, especially when scrap and rework are tracked at the shop-floor level.

    Clear, consistent data structures and version-controlled inspection criteria are important so that defect rate trends can be interpreted correctly over time.

  • KPI steward

    A KPI steward is the person or role accountable for maintaining the integrity of a key performance indicator (KPI) over time. This commonly includes owning the KPI definition, calculation logic, data sources, update rules, and documentation so the metric is interpreted consistently across teams and systems.

    The term usually refers to governance of the metric, not day-to-day operational performance against the metric. A KPI steward may not be the process owner, department manager, or system administrator, although one person can hold more than one of those roles in practice.

    What a KPI steward typically covers

    • Defines what the KPI measures and what it does not measure

    • Maintains calculation rules, units, time windows, and thresholds

    • Identifies the approved system(s) of record and source data

    • Controls changes to the KPI so historical reporting remains understandable

    • Helps resolve disputes about interpretation, lineage, or reporting differences

    • Supports documentation used in dashboards, MES, ERP, QMS, BI, or reporting workflows

    In manufacturing environments, a KPI steward often helps keep measures such as OEE, scrap rate, first pass yield, schedule attainment, nonconformance rate, or on-time delivery aligned across production, quality, and enterprise reporting.

    What it is not

    A KPI steward is not automatically the person entering data, building every dashboard, or approving management decisions based on the KPI. The role is centered on metric governance and consistency. It also does not necessarily mean legal ownership of the underlying data platform.

    Common confusion

    KPI steward vs. KPI owner: A KPI owner is often the person accountable for business results tied to the metric. A KPI steward is commonly responsible for metric definition, lineage, and consistency. Some organizations combine these roles, but they are not the same by default.

    KPI steward vs. data steward: A data steward usually governs data elements or datasets more broadly. A KPI steward focuses on a specific business metric, including how multiple data elements are combined and interpreted.

    KPI steward vs. report owner: A report owner may maintain a dashboard or report format, while a KPI steward maintains the meaning and logic of the KPI itself.

    Why the role appears in regulated operations

    In regulated or highly controlled manufacturing, the same KPI may appear in MES, ERP, QMS, spreadsheet reports, and management reviews. A KPI steward helps reduce ambiguity when teams compare values across systems, time periods, or sites. This is especially relevant when a metric is used for performance review, quality trending, escalation, or audit evidence preparation.

  • MTBF

    MTBF stands for Mean Time Between Failures. It is a reliability metric that estimates the average time a repairable asset or component operates before an inherent (not human-induced) failure occurs. In industrial and manufacturing environments, MTBF is commonly used for equipment, production lines, control systems, and automation components.

    What MTBF represents

    MTBF is typically expressed as hours of operation between failures and is calculated over a defined observation period or based on reliability modeling. It assumes that:

    • The asset is repairable and returned to service after each failure.
    • Failures are random and occur under stated operating conditions.
    • The failure rate is approximately constant within the considered time window.

    In formula form, MTBF commonly refers to total operating time divided by the number of failures in that time period, for the population or single asset under analysis.

    Use in manufacturing and operations

    In regulated and high-uptime manufacturing environments, MTBF is used to describe and track the reliability of:

    • Production equipment (e.g., CNC machines, ovens, assembly cells).
    • Automation and control hardware (PLCs, drives, sensors, HMIs).
    • OT and IT infrastructure supporting MES, SCADA, and data collection.

    Operationally, MTBF can feed into:

    • Availability and OEE calculations as an input to planned/unplanned downtime analysis.
    • Maintenance planning and spare parts strategies for critical assets.
    • Risk and reliability assessments when qualifying equipment or processes.

    In KPI frameworks such as ISO 22400, MTBF is part of the broader set of availability and reliability indicators that support performance visibility and root cause investigations for downtime.

    What MTBF does not cover

    MTBF does not measure:

    • How long it takes to repair equipment after failure (this is typically MTTR).
    • Process yield, product quality, or scrap rates.
    • Operator errors, changeovers, or planned shutdowns unless they are explicitly defined as failures in the data model.

    MTBF is a statistical indicator, not a guaranteed minimum life or warranty period. It should be interpreted alongside other metrics such as MTTR, availability, and quality KPIs.

    Common confusion

    • MTBF vs. MTTF: MTTF (Mean Time To Failure) is usually used for non-repairable items that are discarded after failure, while MTBF is used for repairable assets returned to service.
    • MTBF vs. MTTR: MTTR (Mean Time To Repair or Restore) describes the average time required to repair or restore a failed asset, not the time between failures.
    • MTBF vs. Availability: Availability depends on both MTBF and MTTR. High MTBF with long MTTR can still result in low availability.

    Context in KPI and reliability programs

    In a reliability-centered maintenance or asset management program, MTBF may be trended over time per asset, asset class, or line, often integrated into MES, CMMS, or operations-intelligence tools. In regulated industries, consistent definitions of what constitutes a failure, how operating time is measured, and how data is captured are important for using MTBF as a reliable KPI.

  • KPI ownership

    KPI ownership commonly refers to the clear assignment of responsibility for a specific key performance indicator (KPI) to an individual role, team, or function. The KPI owner is accountable for how the metric is defined, how data is collected, and how the organization responds when performance varies.

    What KPI ownership includes

    In industrial and regulated manufacturing environments, KPI ownership typically covers:

    • Definition and scope: Ensuring the KPI has a clear definition, formula, units, and data sources (for example, defining how OEE or on-time delivery is calculated across plants).
    • Data quality and integrity: Working with IT/OT, MES, ERP, and quality systems to confirm that input data is available, consistent, and traceable.
    • Monitoring and review: Regularly reviewing KPI results, trends, and variation across shifts, lines, suppliers, or sites.
    • Escalation and action: Initiating investigations, corrective actions, or continuous improvement activities when targets are missed or unusual variation appears.
    • Governance and communication: Keeping documentation, dashboards, and reporting rules current so that different stakeholders interpret the KPI consistently.

    Where KPI ownership shows up operationally

    In practice, KPI ownership often appears in:

    • Production and operations: Line or value stream managers owning KPIs such as throughput, OEE, scrap rate, and changeover time, typically fed by MES or OT data.
    • Quality management: Quality leaders owning defect rates, CAPA cycle time, first-pass yield, or supplier quality metrics from QMS and inspection systems.
    • Supply chain and planning: Materials or planning teams owning KPIs such as on-time delivery, schedule adherence, shortages, and inventory turns, often driven by ERP/MRP data.
    • Compliance and audit readiness: Designated owners for KPIs that support quality system performance, audit findings, or regulatory reporting.

    In many organizations, KPI ownership is documented in RACI charts, management review procedures, or metric governance standards so that there is no ambiguity about who maintains each KPI and who is accountable for results.

    What KPI ownership does not mean

    • It does not mean the owner personally performs all work that affects the KPI.
    • It does not guarantee that the KPI meets any external standard or certification requirement.
    • It does not replace cross-functional responsibility for performance; it clarifies who coordinates and stewards the metric.

    Common confusion

    • KPI ownership vs. KPI visibility: Many people may see a KPI on dashboards, but there is usually one defined owner accountable for its definition and performance management.
    • KPI ownership vs. data ownership: Data ownership focuses on who manages the underlying data assets and systems (for example, MES or ERP). KPI ownership focuses on the metric built from that data and the operational response.

  • Continuous Monitoring

    Continuous monitoring commonly refers to the ongoing, often automated, collection and review of data from systems, equipment, or processes to detect changes, anomalies, or nonconformances in near real time. In industrial and regulated manufacturing environments, it is used both for cybersecurity and for operational or quality oversight.

    Operational meaning in manufacturing

    In manufacturing, continuous monitoring typically includes:

    • Production and process data: Tracking parameters such as temperature, pressure, torque, cycle time, and machine status to identify deviations from defined limits or standard work.
    • Quality indicators: Monitoring defect rates, measurement results, SPC charts, and inspection outcomes to catch emerging nonconformances earlier.
    • Equipment condition and performance: Observing utilization, downtime, alarms, and maintenance indicators to support OEE analysis and reliability programs.
    • Data integrity and traceability: Automatically logging who did what, when, and on which part or lot, including changes to work instructions, routings, and records.

    Continuous monitoring may be implemented through MES, SCADA, historians, machine connectivity, quality systems, or specialized monitoring tools. Alerts, dashboards, and reports are commonly used to surface issues to operators, supervisors, quality engineers, and IT/OT teams.

    Cybersecurity and compliance context

    In cybersecurity and regulated manufacturing, continuous monitoring also refers to ongoing oversight of information systems and networks, for example:

    • Tracking user access, authentication attempts, and privileged activities on OT and IT systems.
    • Monitoring for abnormal network traffic, unauthorized connections, or configuration changes in industrial control systems.
    • Collecting security-relevant logs from MES, ERP, file servers, and other applications for review and correlation.
    • Maintaining evidence that required controls are active and functioning over time, in support of internal policies or external frameworks (such as cybersecurity or data protection requirements).

    In this sense, continuous monitoring supports risk management by helping organizations detect potential security incidents or control failures in a timely manner, rather than relying only on periodic audits.

    What continuous monitoring is not

    • It is not a one-time audit, assessment, or inspection. Those are point-in-time activities, while continuous monitoring is ongoing.
    • It is not limited to a single department. It can span production, maintenance, quality, IT, and OT.
    • It is not a guarantee of compliance or security. It is a method of collecting information to support oversight and decision-making.

    Common confusion

    • Continuous monitoring vs. periodic monitoring: Periodic monitoring uses scheduled checks (for example, weekly or monthly reviews). Continuous monitoring relies on near real-time or high-frequency data collection and alerting.
    • Continuous monitoring vs. control: Monitoring observes and reports on the state of systems or processes. Control functions (such as interlocks, PLC logic, or automated shutdowns) act on that information. Many industrial systems use both, but they are distinct concepts.
    • Continuous monitoring vs. continuous improvement: Continuous improvement focuses on systematically enhancing processes. Continuous monitoring provides data and visibility that can feed those improvement efforts but is not an improvement methodology by itself.

    Use in regulated manufacturing

    In regulated or high-risk environments, continuous monitoring is often applied to:

    • Maintain consistent records of process conditions and product history for traceability.
    • Support detection, investigation, and documentation of nonconformances and CAPA activities.
    • Provide ongoing evidence that certain operational, quality, or cybersecurity controls are functioning as intended.