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

KPI definition, measurement logic, and financial impact modeling.

  • KPI

    Core meaning

    A **KPI (Key Performance Indicator)** is a defined, measurable metric used to assess how effectively an organization, process, or system is achieving a specific objective. In industrial and regulated manufacturing environments, KPIs are typically quantitative measures derived from operational data, used to monitor performance, compliance, and improvement over time.

    A KPI normally includes:

    – A clear objective it is intended to measure
    – A precise definition of the metric and units
    – A data source (systems, sensors, manual entries)
    – A calculation method and aggregation rules
    – A defined scope (time period, equipment, product, site)

    Use in industrial and manufacturing workflows

    In manufacturing, KPIs are commonly used to monitor production, quality, and reliability. Examples include:

    – **OEE (Overall Equipment Effectiveness)** based on availability, performance, and quality
    – **First pass yield** or right-first-time rate per line or product
    – **Scrap or rework rate** as a percentage of produced quantity
    – **On-time delivery performance** by order, batch, or customer
    – **Batch cycle time** or throughput per work center

    These KPIs may be calculated from data in MES, historians, SCADA, ERP, LIMS, or quality systems, and are often displayed in operations dashboards, shift reports, or management reviews.

    Data trust and KPI reporting (site context)

    Where KPIs are derived from MES and other OT/IT systems, organizations commonly treat them as part of a governed reporting environment. In that context:

    – KPI definitions are documented and version-controlled
    – Data lineage (source systems, transformations, and calculations) is traceable
    – Calculations are validated and periodically reconciled against physical reality and independent data sources
    – Changes to KPI logic, data sources, or system configurations follow formal change control

    This is particularly important in regulated environments, where KPI reporting may be used to support internal decision-making, investigations, or regulatory inspections.

    Boundaries and what KPIs are not

    – A KPI is **not** just any data point; it is a metric explicitly tied to an objective and governed definition.
    – A KPI is **not** the same as raw operational data. It is usually an aggregation, calculation, or rate derived from underlying data.
    – A KPI is **not** a corrective action or improvement plan. It indicates performance status but does not, by itself, define what should be done.

    Common confusion and related terms

    – **KPI vs. metric:** All KPIs are metrics, but not all metrics are KPIs. A KPI is a metric designated as critical for monitoring objectives and is usually governed more tightly.
    – **KPI vs. SLA (Service Level Agreement):** An SLA is a formal commitment or target; KPIs are measures used to monitor whether such targets are being met.
    – **KPI vs. KRI (Key Risk Indicator):** KRIs focus on the likelihood or impact of risks, while KPIs focus on performance toward operational or business goals. In practice, some indicators may function as both.

    In industrial operations, KPIs are typically part of a broader performance-management framework that may include dashboards, alerts, root cause analysis, and continuous improvement activities.

  • Service Level Agreement (SLA)

    Core meaning

    A **Service Level Agreement (SLA)** is a formal document or contractual section that defines the expected level of service between a service provider and a customer. It specifies measurable performance targets, how those targets are measured, responsibilities of each party, and what happens if the agreed levels are not met.

    In industrial and regulated environments, SLAs are commonly used for:

    – IT and OT infrastructure services (networks, servers, industrial PCs)
    – Hosted or managed MES, ERP, LIMS, and quality systems
    – External calibration, maintenance, and equipment service providers
    – Cloud services that support manufacturing operations (e.g., data historians, analytics)

    An SLA is usually one part of a broader contract or master service agreement (MSA), focused specifically on service performance and measurement.

    Typical contents in manufacturing and OT contexts

    While structure varies, SLAs in industrial operations commonly include:

    – **Scope of services**: Which systems, plants, or functions are in scope (e.g., MES production scheduling, shop-floor network support).
    – **Service availability**: Target uptime (e.g., 99.9% monthly availability), maintenance windows, and exclusions.
    – **Response and resolution times**: Time targets for acknowledging and resolving incidents, often by severity or priority level.
    – **Performance metrics (SLIs)**: Defined service level indicators such as response time, transaction throughput, backup frequency, or data restore time.
    – **Support hours and channels**: When and how support is provided (e.g., 24/7 for critical OT, business hours for non-critical systems).
    – **Responsibilities and dependencies**: Obligations on both sides, including customer duties (e.g., providing access, following change procedures).
    – **Monitoring and reporting**: How performance is monitored, how often reports are provided, and how metrics are calculated.
    – **Exception handling**: How breaches are identified, communicated, and managed, including remediation actions.

    In regulated environments, SLAs may also cross-reference quality agreements, validation status, and documentation requirements, without themselves serving as proof of regulatory compliance.

    Boundaries and exclusions

    – An **SLA defines performance targets**; it is not the same as:
    – A **statement of work (SOW)**, which describes tasks and deliverables.
    – A **quality agreement**, which focuses on GMP/GxP or quality responsibilities.
    – Internal **standard operating procedures (SOPs)**, which describe how work is executed.
    – SLAs do **not in themselves guarantee** regulatory compliance or product quality; they only describe service performance commitments.
    – SLAs can apply to **internal shared services** (e.g., corporate IT serving multiple plants) or **external vendors**; the concept is the same.

    Use in real workflows and systems

    In manufacturing operations, SLAs are used to:

    – Define acceptable downtime and recovery expectations for MES, SCADA, historians, and other critical OT systems.
    – Align plant operations, IT/OT teams, and vendors on incident handling priorities and timelines.
    – Support risk assessments by quantifying the impact of system unavailability on production and release processes.
    – Provide a basis for periodic service reviews and performance discussions with providers.

    For example, a plant may have an SLA stating that the MES must be available 99.95% during production hours, with critical incidents acknowledged within 15 minutes and resolved or mitigated within 2 hours where feasible.

    Common confusion and related terms

    – **SLA vs. SLO vs. SLI**:
    – **SLI (Service Level Indicator)**: The specific metric (e.g., “MES order download success rate”).
    – **SLO (Service Level Objective)**: The internal target for that metric (e.g., 99.95% success rate over 30 days).
    – **SLA**: The formal, usually contractual, commitment that may bundle several SLOs and define consequences for non-compliance.
    – **SLA vs. OLA (Operational Level Agreement)**:
    – An **OLA** is typically an internal agreement between teams (e.g., OT and IT) to support meeting the SLA; it is usually not customer-facing.

    Site context application

    Within the context of industrial operations and manufacturing systems, a Service Level Agreement (SLA) commonly refers to the documented expectations and measurable commitments around availability, responsiveness, and support for systems such as MES, ERP, quality systems, and OT infrastructure that support regulated production and quality workflows.

  • Throughput

    Throughput commonly refers to the rate at which a process, line, plant, or system produces usable output over a defined period of time. In manufacturing, it is typically expressed as units per hour, batches per shift, or a similar time-based measure, and focuses on output that meets release criteria.

    What throughput includes

    In regulated industrial operations, throughput usually:

    • Counts only finished goods or intermediates that meet quality and compliance requirements
    • Is measured over a clear time window (for example, per hour, shift, day, or week)
    • Is tied to a specific constraint, process step, line, or facility
    • Is based on governed data from systems such as MES, SCADA, historians, or ERP

    Depending on the context, organizations may distinguish between:

    • Gross throughput: total units output, including scrap and rework
    • Net or good throughput: only units that are conforming and accepted

    Operational use in manufacturing

    Throughput is a core performance KPI used in production planning, capacity analysis, and continuous improvement. Common uses include:

    • Comparing actual output against scheduled or theoretical capacity
    • Monitoring the impact of downtime, changeovers, or maintenance on output rate
    • Supporting on-time delivery metrics and service-level analysis
    • Feeding into composite KPIs such as Overall Equipment Effectiveness (OEE), where the performance component reflects throughput relative to a standard

    Throughput can be defined at different levels, for example:

    • Single machine or unit operation (for example, vials per minute filled)
    • Production line or work cell (for example, kits per hour packaged)
    • Plant or network level (for example, lots per week released)

    Common confusion

    Throughput is often confused or interchanged with related terms:

    • Capacity: capacity is the maximum sustainable output rate under defined conditions. Throughput is the actual achieved rate in a given period.
    • Output: output is a quantity (for example, 10,000 units). Throughput is a rate (for example, 10,000 units per day).
    • Yield: yield describes the proportion of conforming product versus total processed. Throughput describes how fast output is produced.

    In IT and OT networking, throughput can also refer to the rate of data transfer over a communication channel (for example, megabits per second). In the context of production KPI discussions and MES data, the manufacturing output meaning is usually intended.

    Link to the KPI context

    In KPI frameworks for manufacturing, throughput is frequently paired with on-time delivery to evaluate whether a plant or line is producing at a rate that supports customer commitments. In regulated, brownfield environments, organizations typically need clearly governed definitions and consistent data sources so that throughput is calculated the same way across sites and systems.

  • continuous improvement

    Continuous improvement in manufacturing

    Continuous improvement is an ongoing, structured approach to refining processes, practices, and standards to reduce waste, variation, errors, and recurring issues. It focuses on making frequent, incremental changes rather than occasional large projects, using evidence from operations to drive better performance over time.

    In industrial and regulated environments, continuous improvement typically relies on:

    – Regularly collected data from production, quality, and maintenance systems
    – Feedback from frontline operators, engineers, and support teams
    – Clear performance measures (for example, safety, quality, delivery, cost, and compliance indicators)
    – Documented methods to identify problems, test changes, and sustain gains

    Methods and typical activities

    Continuous improvement commonly uses defined cycles such as plan–do–check–act (PDCA) or similar problem-solving frameworks. Typical activities include:

    – Root cause analysis of quality deviations, equipment failures, or process upsets
    – Small-scale trials or experiments on the line to validate proposed changes
    – Updating standard work, procedures, and work instructions after successful tests
    – Training operators and supervisors on new methods or controls
    – Follow-up reviews and monitoring to confirm that improvements are stable and repeatable

    The results are used to update procedures, training materials, digital forms, and system configurations (for example, MES, LIMS, or maintenance systems) so that improvements become part of everyday operations rather than one-time events.

    Connection to manufacturing systems and compliance

    In modern manufacturing, continuous improvement is closely linked to shop-floor and enterprise systems:

    – Manufacturing execution systems (MES) and quality systems provide real-time data on defects, downtime, and process trends that highlight improvement opportunities.
    – ERP, maintenance, and operations intelligence tools help track the impact of changes on throughput, cost, and reliability.
    – In regulated environments, improvement activities must be documented, risk-assessed, and incorporated into controlled procedures and records to maintain traceability and support audits.

    Continuous improvement complements, but does not replace, formal change control, risk management, and quality management processes. It provides the operational discipline for continually refining how work is done within those controlled frameworks.

  • On-Time Delivery (OTD)

    Core meaning

    On-time delivery (OTD) is a performance metric that measures how reliably an organization delivers products or services on or before the date promised to the customer or downstream process. It is usually expressed as a percentage of total deliveries within a defined period.

    In manufacturing and industrial operations, OTD commonly refers to:

    – Customer order OTD: shipments leaving the plant or distribution center on or before the committed ship or delivery date.
    – Internal OTD: work orders, batches, or components supplied on time to internal customers, such as assembly lines, packaging, or downstream plants.

    How OTD is typically calculated

    There is no single universal formula, but many organizations use variants of:

    – **OTD % = (Number of on-time deliveries ÷ Total number of deliveries) × 100**

    Key design choices that differ by organization include:

    – What counts as the **reference date** (requested date vs. confirmed/committed date).
    – What defines **on time** (exact date, on or before the date, or within a defined window).
    – What the **unit of measure** is (order lines, shipments, order headers, pallets, or internal work orders).

    These choices must be defined clearly in procedures and systems so reported OTD is consistent and auditable.

    Use in industrial and regulated environments

    In industrial and regulated manufacturing environments, OTD is commonly used to:

    – Monitor supply reliability for finished goods and intermediates.
    – Assess the performance of production lines, plants, and contract manufacturers.
    – Evaluate supplier reliability for raw materials, components, or packaging.
    – Support service-level commitments in quality agreements and internal service-level arrangements.

    OTD may be tracked at multiple levels, such as by product family, customer, market, production line, or supplier.

    Role in operations, MES, and ERP

    In integrated OT/IT landscapes:

    – **ERP systems** usually hold customer orders, committed dates, and shipment records used to calculate customer-facing OTD.
    – **MES or production management systems** track work order start/finish times and internal due dates for in-process steps, supporting internal OTD metrics (e.g., batch release OTD, line supply OTD).
    – **Advanced planning and scheduling tools** use OTD measures to assess adherence to production plans and dispatch lists.
    – **Operations intelligence and dashboards** often expose OTD as a key service-level indicator alongside quality and cost.

    Data integrity (timestamps, confirmations, schedule changes) is essential so OTD values are traceable and reproducible.

    Boundaries and what OTD is not

    On-time delivery:

    – **Is a timeliness/reliability metric**, not a direct measure of quality or cost.
    – **Does not inherently state quantity accuracy** (an order may be on time but short shipped, depending on how the metric is defined).
    – **Does not replace other metrics** such as fill rate, perfect order, inventory turns, or schedule adherence, though it is often used in combination with them.

    Because of this, many organizations define additional metrics (e.g., on-time in-full, OTIF) to supplement OTD.

    Common variations and related measures

    Common variants and related metrics include:

    – **On-time in-full (OTIF)**: measures deliveries that are both on time and complete vs. order quantity.
    – **Perfect order**: combines timeliness with completeness, accuracy, and sometimes documentation correctness.
    – **Schedule adherence / plan adherence**: measures execution against the production schedule rather than against customer dates.

    Clear terminology is important so OTD is not confused with these broader or more restrictive metrics.

    Common sources of confusion or misuse

    Frequently observed issues include:

    – **Unclear date definition**: mixing requested date and committed date in the same metric, making trends unreliable.
    – **Ignoring partial or split shipments**: counting an order as on time when only part of the requirement shipped, or counting each split differently across plants.
    – **Changing dates retrospectively**: updating committed dates late in the process to improve apparent OTD, which undermines the metric’s usefulness for performance analysis.
    – **Comparing OTD across entities with different rules**: benchmarking sites, suppliers, or business units without aligning calculation methods.

    Documented definitions, system configuration, and governance are usually required to keep OTD meaningful and comparable over time.

    Site context application

    Within the context of industrial operations and regulated manufacturing systems, on-time delivery (OTD) is a key KPI used in:

    – Manufacturing execution and scheduling, where MES and ERP data are combined to evaluate order and batch timeliness.
    – Quality and compliance reporting, where OTD can be monitored alongside rejection rates or release lead times.
    – Supplier and contract manufacturer performance management, especially when integrated with quality systems and audits.

    It is commonly visualized in shop-floor visibility tools, operations intelligence platforms, and management dashboards as an indicator of service reliability and process stability.