Connect981 – Content Dev

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

KPI definition, measurement logic, and financial impact modeling.

  • time categories

    Time categories are standardized buckets used to classify how time is spent in a manufacturing or maintenance, repair and overhaul (MRO) environment. They provide a structured way to break total calendar time into meaningful segments, so that systems and analysts can measure utilization, performance, and causes of delay in a consistent way.

    In industrial operations, time categories are commonly applied to equipment, production lines, assets, or work orders. They appear in MES, CMMS/EAM, and analytics tools as coded states or event types that describe what is happening during a given time interval.

    Typical structure of time categories

    While naming varies by organization and standard, time categories often follow a hierarchy, for example:

    • Calendar / total time: 24/7 time, including both working and non-working periods.
    • Available vs. non-available time:
      • Available time: Time when an asset or resource is scheduled or allowed to run.
      • Non-available time: Time when it is not expected to run (e.g., holidays, long-term shutdowns).
    • Within available time:
      • Operating / productive time: Time spent executing value-adding production or maintenance work.
      • Planned loss: Scheduled activities that stop normal operation, such as planned maintenance, changeovers, inspections, or training.
      • Unplanned loss: Unscheduled events that reduce output, such as breakdowns, waiting for material, rework, or quality inspections triggered by issues.

    Each high-level time category can be further split into more detailed subcategories, such as specific types of downtime, setup, quality-related delays, or logistics-related waiting time.

    Operational use in systems and KPIs

    Time categories are used to:

    • Map MES or CMMS event codes (e.g., machine state, work order status) into standardized buckets.
    • Calculate KPIs such as OEE, non-productive time (NPT), utilization, and turnaround time (TAT) components.
    • Enable cross-site comparisons by normalizing different local codes into a shared time model.
    • Support root cause and bottleneck analysis by linking delays to clear, agreed categories.

    Standards such as ISO 22400 describe reference time category models for manufacturing KPI calculation. Organizations often use these as a starting point and extend them with sector-specific categories, for example detailed MRO turnaround states.

    Use in MRO and turnaround management

    In MRO, time categories are frequently applied at the work-package or asset level to break down turnaround time into events such as induction, inspection, teardown, repair, test, rework, waiting for parts, and customer hold. These detailed events are then aligned with more generic time categories in plant-wide KPI models so that MRO performance can be compared to other manufacturing operations.

    Common confusion

    • Time categories vs. event codes: Event codes are the raw labels or status values recorded by systems (for example, “Setup”, “Waiting for QC”). Time categories are the standardized buckets those events are mapped into for analysis.
    • Time categories vs. shifts or calendars: Shifts and calendars define when work is planned. Time categories describe what actually happened during that time.
    • Time categories vs. KPIs: KPIs are metrics (for example, OEE or TAT). Time categories are an input structure that supports calculating and interpreting those metrics.

  • TEEP

    TEEP stands for Total Effective Equipment Performance. In industrial and manufacturing environments it is a utilization metric that extends OEE by including all calendar time, not just planned production time.

    Core definition

    TEEP commonly refers to the percentage of total calendar time that an asset, line, or plant actually uses to produce good product at the target rate. A typical high-level formula is:

    • TEEP = OEE × Loading

    Where, in many TPM and ISO 22400 style interpretations:

    • OEE (Overall Equipment Effectiveness) measures effectiveness during planned production time only (availability, performance, and quality losses within that window).
    • Loading (sometimes called utilization) measures what share of total calendar time is designated as planned production time.

    Under this view, TEEP expresses how close the equipment is to its theoretical maximum output if it were available and scheduled to run 24 hours a day, 7 days a week.

    Operational meaning in manufacturing

    In practice, TEEP is used to provide visibility into both:

    • How intensively equipment is scheduled (loading across shifts, weekends, holidays).
    • How effectively equipment runs when scheduled (the OEE components of availability, performance, and quality).

    On many shop floors, TEEP appears in performance dashboards, MES or operations intelligence systems as a high-level capacity and utilization indicator. Typical usage includes:

    • Comparing effective utilization across lines, plants, or assets that run on different shift patterns.
    • Assessing whether to add shifts, re-balance loading, or pursue continuous improvement on existing shifts.
    • Separating business decisions about scheduling and demand from technical or process losses inside scheduled time.

    Because TEEP is based on calendar time, it is sensitive to how an organization defines total time, planned downtime, and non-production days. These definitions need to be documented in systems and reports, especially in regulated environments.

    Relationship to OEE and ISO 22400

    In many TPM-style implementations, TEEP is described alongside OEE as part of a family of equipment-related KPIs. ISO 22400 series standards describe related concepts such as availability, utilization, and other manufacturing performance indicators, but terminology and formulas may differ from legacy TPM practices.

    Where both TPM-style OEE and ISO 22400 terminology are used, organizations commonly:

    • Map TEEP clearly to the underlying ISO 22400 metrics (for example, which time categories are included in loading and availability).
    • Document any alternate formulas or naming used locally so that system reports and audit evidence remain consistent.

    What TEEP includes and excludes

    In its typical manufacturing usage, TEEP:

    • Includes all calendar time for the measurement period (for example, 24×7 over a week or month).
    • Includes both production and non-production periods when calculating loading.
    • Excludes any notion of theoretical design limits beyond the chosen reference speed and quality assumptions already embedded in OEE.

    TEEP does not by itself distinguish between different reasons for low utilization (such as low demand, maintenance strategy, staffing limits, or technical downtime). Those factors are usually tracked in supporting loss or time models linked to OEE and scheduling.

    Common confusion

    • TEEP vs. OEE: OEE looks only at effectiveness during planned production time. TEEP extends this by considering how much of total calendar time is actually planned and used for production. High OEE with low TEEP often indicates under-loading or limited shift patterns rather than poor equipment performance.
    • TEEP vs. utilization or capacity utilization: Some plants use “utilization” to mean loading, and others use it to mean something closer to TEEP. To avoid confusion, it is helpful to specify the exact formula used for TEEP and any related utilization metric in performance reports and MES configurations.

    Derived-from context: TPM-style and ISO 22400 usage

    In TPM-style OEE environments, TEEP is often presented as a legacy or local KPI that complements OEE by revealing calendar-based capacity use. When organizations adopt ISO 22400 terminology, they frequently keep TEEP as an internal indicator while explicitly documenting how its formula maps to the standard’s time and performance definitions so that reports, system integrations, and audits remain clear.

  • First-Pass Yield (FPY)

    First-Pass Yield (FPY) is a quality and performance metric that measures the percentage of units that successfully pass through a process or operation the first time, without requiring any rework, repair, or additional processing and without being scrapped.

    In industrial and regulated manufacturing environments, FPY is commonly calculated at the operation, work center, line, or process-step level. It focuses on whether each unit meets all specified requirements and inspection criteria in its first pass through that defined scope.

    How First-Pass Yield is commonly calculated

    A typical FPY calculation is:

    • FPY = (Number of good units out of the process on first attempt) ÷ (Total units entering the process)

    “Good units” in FPY explicitly excludes any items that required rework, repair, extra processing, or concession, even if they were eventually accepted. Scrapped units are also excluded from the numerator.

    Where FPY is used in manufacturing

    • Process monitoring: Tracking FPY at key operations (e.g., machining, coating, assembly, test) to understand process performance.
    • Quality management: Using FPY to help identify processes that generate nonconformances, rework, or concessions.
    • MES and shop-floor systems: Recording pass/fail results by operation and computing FPY by part, work order, cell, shift, or supplier.
    • Continuous improvement: Trending FPY as part of yield, scrap, and cost-of-poor-quality analysis.

    What First-Pass Yield includes and excludes

    • Includes: Units that meet all requirements in their first complete pass through the specified process scope.
    • Excludes from the numerator:
      • Units that fail inspection and are reworked, repaired, or re-tested.
      • Units that are scrapped.
      • Units accepted only under deviation, waiver, or concession (depending on local definition and procedures).

    The exact treatment of units accepted under deviation or concession should be defined in internal procedures to keep FPY reporting consistent.

    FPY vs related yield metrics

    • First-Pass Yield (FPY): Focuses on a single process or operation and counts only units that pass on their first attempt.
    • Rolled Throughput Yield (RTY): Multiplies the FPY of a sequence of operations to estimate the probability that a unit passes through all those steps without any rework.
    • Overall yield: Often refers to final output versus initial input, including units recovered after rework; this is usually more generous than FPY.

    Common confusion

    • FPY vs overall yield: Overall yield can count reworked units as good, while FPY counts only those that never needed rework.
    • FPY vs defect rate: Defect rate measures the frequency of defects, while FPY measures the proportion of units that clear a process without any defects requiring correction.

    Operational context in regulated environments

    In regulated or highly documented operations, FPY is often linked to digital records in MES, QMS, or ERP systems. Pass/fail outcomes at each operation, nonconformance records, and rework transactions provide the data needed to calculate FPY and to support audits or process reviews without implying any certification or compliance status.

  • Busy Time

    Busy time commonly refers to the period during which a manufacturing resource is actively performing assigned work. It is used in production, maintenance, and capacity analysis to distinguish productive engagement from idle, waiting, or down states.

    What busy time includes

    Depending on the context and data model, busy time typically includes:

    • Active machine processing, such as cutting, molding, filling, or testing parts or batches.
    • Setup and changeover work that is planned and required to support production runs.
    • Direct operator work, such as assembly, inspection, adjustment, or supervised automated runs.
    • Planned maintenance work when the tracked resource is a maintenance team or technician.

    Busy time is usually measured at the level of a specific resource, such as a machine, production line, workstation, operator, or work center.

    What busy time excludes

    Busy time normally excludes:

    • Idle or waiting time, for example when a machine is ready but waiting for material, tooling, or instructions.
    • Unplanned downtime, such as breakdowns, IT/OT outages, or safety stops.
    • Planned downtime, such as scheduled breaks, shutdowns, or holidays, unless the model explicitly counts these separately.
    • Non-utilized capacity where a resource is available but not loaded with work.

    Operational use in manufacturing systems

    In industrial operations and regulated environments, busy time appears in several places:

    • MES and OT systems: Machine states (such as Running, Setup, or In Cycle) are aggregated into busy time for performance analysis.
    • OEE and utilization metrics: Busy time is a key input for calculating utilization, availability, and overall equipment effectiveness, by comparing it to total calendar or planned time.
    • Capacity planning: Planners compare historical busy time to available capacity to identify constraints, load balancing needs, or scheduling limits.
    • Labor tracking: In time and attendance or electronic batch records, operator busy time against specific orders, batches, or tasks is used for costing, traceability, and compliance documentation.

    Relationship to other time categories

    Busy time is often one of several standardized time categories, such as:

    • Available time: The period a resource is scheduled or technically able to run.
    • Busy (productive) time: Subset of available time when the resource is performing assigned work.
    • Idle or standby time: Available but not actively working.
    • Downtime: Not available due to faults, changeovers, or planned shutdowns, depending on how the model is defined.

    Exact boundaries between these categories depend on the site’s data model and standards but should be documented consistently in MES, SCADA, or reporting tools.

    Common confusion

    Busy time is sometimes confused with:

    • Utilization: Utilization is usually a percentage (busy time divided by available time). Busy time is the absolute time value itself.
    • Cycle time: Cycle time refers to the time to complete one unit or batch. Busy time is the aggregate period the resource is actively working, which may cover many cycles and tasks.
    • Run time: Some systems define run time as only in-cycle processing, while busy time may also include setup, adjustments, or inspections. The local definition should clarify whether these are the same or different.

    Typical example in a regulated plant

    On a filling line in a regulated facility, busy time might include the minutes the line is filling product, performing in-process checks, and running validated cleaning cycles. Time waiting for QA release, waiting for components, or under corrective maintenance would be tracked separately as waiting or downtime, not as busy time.

  • How can we estimate the cost of a non-conformance in aerospace production?

    There is no single universal formula for the cost of a non-conformance in aerospace. What you can build is a structured, repeatable model that uses your existing MES/ERP/QMS data and a set of assumptions. The goal is not perfect accuracy, but a consistent way to compare and prioritize issues and investments.

    1. Start with a clear cost-of-poor-quality structure

    Most aerospace plants use a COPQ-style breakdown as a starting point:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Internal failure costs: scrap, rework, MRB, inspections triggered by the NCR.
    • External failure costs: returns, concessions, field repairs, penalties, program reputation impact.
    • Appraisal/containment costs: extra inspections, special audits, temporary checks put in place to contain the issue.
    • Prevention costs (optional in this estimate): engineering changes, training, fixture redesigns. These are often tracked separately from the NCR itself.

    Decide which buckets you will always include in an NCR cost estimate and make that policy explicit. In regulated environments, consistency and traceability of assumptions matter more than precision on any one event.

    2. Quantify the direct "visible" costs first

    Direct costs are typically the easiest to estimate and to pull from existing systems.

    • Scrap material cost
      Use your ERP/finance item cost: unit cost × quantity scrapped. Include special processes or coatings if they cannot be salvaged.
      Dependencies: accurate BOM costs and scrap booking practices.
    • Rework labor
      Estimate hours spent on rework × loaded labor rate (wages + burden). Hours should include:
      • Operators doing rework
      • Inspectors re-verifying
      • Setups required only because of the NCR

      Dependencies: time-tracking discipline, realistic standard times for rework operations, or at least a documented estimating guideline.

    • Rework materials and consumables
      Special tooling, replacement components, consumables (abrasives, chemicals, hardware) that are used only because of the NCR. These are usually small per event but can be significant for complex assemblies.
    • MRB / engineering / quality analysis time
      Estimate time spent by MRB, quality, and engineering on:
      • Dispositioning the NCR
      • Risk assessments
      • RCCA / 8D or similar activities attributable to this issue

      Multiply total hours by appropriate loaded rates or by a standard blended rate for "technical problem-solving hours."

    For many plants, putting in place a simple template for these four elements already improves NCR cost visibility dramatically.

    3. Add internal disruption and schedule impact where material

    Internal disruption is harder to quantify, but for significant NCRs it often dominates the actual economic impact.

    • Line stoppage / lost capacity
      When an NCR halts a cell, line, or key machine, estimate:
      • Duration of effective stoppage or slowdown
      • Typical value-add per hour (often from OEE, revenue per capacity hour, or a proxy)

      Cost impact ≈ hours of lost capacity × value per capacity hour.
      Constraint: This is a model, not a GAAP number. Make its use explicit and use it mostly for prioritization.

    • Expediting and rescheduling
      Include extra changeovers, overtime, or premium freight specifically caused by the NCR. These are often visible already as separate cost codes in ERP or finance if your plant uses them.
    • Work-in-process disruption
      When the NCR affects assemblies already in flow, include:
      • Extra handling / segregation operations
      • Additional inventory days in WIP (if you cost inventory holding)

      These are often rough-order estimates unless you have a mature value-stream accounting model.

    4. Include external and customer-facing costs when applicable

    In aerospace, the risk of external non-conformance is often far more consequential than internal scrap. You should distinguish between:

    • Confirmed external events (e.g., field finding, return, or OEM escape):
      • Direct repair or replacement cost (parts, labor, travel if field repair)
      • Customer charges, fees, or penalties documented in contracts
      • Additional inspections mandated by customer or regulator
    • Potential external impact (e.g., escapes caught before flight or before delivery):
      • Recall or containment activities in downstream plants or depots
      • Data reviews and documentation updates required to demonstrate continued airworthiness or compliance

    Many organizations choose to separate "accounting" cost from "risk" cost. For example:

    • Use actuals (documented invoices, chargebacks, travel expenses) for the NCR cost record.
    • Track potential or avoided cost in a separate risk/lessons-learned log, rather than in the NCR cost field itself.

    This avoids mixing speculative risk numbers into financial reporting while still acknowledging the real exposure.

    5. Use your existing systems, but accept brownfield limits

    In most aerospace plants, NCR cost data is spread across multiple systems:

    • ERP: material cost, scrap postings, labor bookings, freight, overtime codes.
    • MES / digital travelers: where and when the defect occurred, rework operations, routing changes.
    • QMS / NCR system: MRB decisions, defect classification, containment actions, 8D / RCCA records.
    • PLM / change control: engineering changes, redesigned tooling or process updates.

    Replacing these systems outright just to improve NCR costing is rarely realistic in regulated, long-lifecycle environments due to validation burden, qualification, and downtime risk. A more practical approach is:

    • Define a standard NCR cost model (what to include, at what level of precision).
    • Implement lightweight integrations or reports that pull a minimal data set from ERP/MES into the NCR record.
    • Use standard fields and picklists in the QMS or MES NCR module so data can be analyzed over time.
    • Validate only the data flows that matter for decisions and audit trails, not a fully automated costing engine from day one.

    Expect some manual inputs to remain, especially for engineering and MRB labor time, disruption estimates, and special customer actions.

    6. Make assumptions explicit and repeatable

    Whatever model you use, document it. In regulated aerospace environments, auditors and customers will often ask "how did you come up with these cost numbers?" You should be able to show:

    • Which cost elements must be filled out for every NCR.
    • Which elements are only for major NCRs (e.g., line-stoppage cost, external impact).
    • Standard rates and rules, such as:
      • Loaded labor rate assumptions by role
      • Default time estimates for typical MRB review steps, if actual time is not tracked
      • How you assign disruption cost to a specific NCR when many issues occurred in a period
    • Who can override or adjust estimates and how changes are documented.

    This both improves internal decision-making and reduces friction during audits and customer reviews.

    7. Use NCR cost data for trends and prioritization, not just "true cost"

    Even with a disciplined approach, single-event NCR cost numbers will always be approximations. They are most powerful when used in aggregate:

    • Identify top cost drivers by defect type, product, process, supplier, or cell.
    • Compare internal vs external failure mix and track shift over time.
    • Build a business case for automation, fixturing, digital work instructions, or supplier development using trend data rather than anecdote.

    Be careful not to over-rotate on a single dramatic NCR cost. Focus on patterns supported by consistent data.

    8. Practical starting template for an aerospace NCR

    If you do not yet have a structured method, a simple, implementable template for each NCR is:

    1. Scrap cost: material + special process cost.
    2. Rework labor cost: rework hours × loaded rate.
    3. Rework material / tooling cost: parts and consumables.
    4. MRB / engineering / quality time: hours × blended technical rate.
    5. Disruption cost (if applicable): model-based estimate of lost capacity or premium freight.
    6. External / customer cost (if applicable): documented charges, returns, travel, or mandated inspections.

    Sum 1–4 for a baseline internal NCR cost. Add 5–6 for full impact on significant events. Use clear flags in your system so you can analyze "baseline" and "full impact" separately.

    9. Dependencies and limitations to acknowledge

    When communicating NCR cost numbers internally, be transparent about:

    • Data quality limits: missing labor bookings, inaccurate routings, or inconsistent scrap coding will reduce precision.
    • Scope decisions: whether you exclude prevention costs or long-term reputation/contract impacts.
    • Attribution challenges: when multiple issues affect the same schedule slip or disruption, cost allocation is a management decision, not a precise science.
    • Validation boundaries: which parts of your costing approach are validated or relied on in formal reporting versus used only for operational decision support.

    Being explicit about these constraints usually improves confidence in the data, because stakeholders understand what the numbers are and are not.

  • Do all systems need to be upgraded to support ISO 22400?

    No. You do not need to upgrade every system just to “support ISO 22400.” ISO 22400 defines manufacturing operations KPIs and terminology, not a mandatory software feature set or certification scheme. In most regulated, brownfield environments, you align data and reporting to ISO 22400 across your existing stack, and only change or upgrade systems where it is necessary and justified.

    What ISO 22400 actually requires

    ISO 22400 focuses on:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Common definitions for KPIs such as OEE, availability, performance, and quality
    • Standardized naming for states, quantities, and time categories
    • Conceptual models of how metrics should be derived from production data

    It does not require that each MES, historian, PLC, or ERP module be “ISO 22400 certified” or upgraded to a specific version. Compliance is mainly about how you define, calculate, document, and use metrics.

    Typical brownfield approach

    In a mixed-vendor, long-lived environment, the practical path is usually:

    1. Define your target ISO 22400 model
      Document exactly how your organization will interpret the ISO 22400 KPIs, time categories, and states. This should be under change control and traceable.
    2. Map existing data sources to the model
      Identify where needed data currently resides (PLCs, SCADA, MES, historian, manual logs, ERP). Create a mapping showing how each source contributes to each metric and what translation is required.
    3. Standardize calculations in one or a few layers
      Instead of upgrading every system, centralize calculations where feasible: in MES, a data warehouse, or an analytics layer. Legacy systems can continue to produce their native tags and states, which are translated to ISO 22400 semantics downstream.
    4. Use adapters and integration, not wholesale replacement
      For older equipment or software that cannot be changed easily, use integration logic or middleware to normalize signals, event codes, and time categories into the ISO 22400 model.
    5. Adjust or upgrade selectively
      Only upgrade or reconfigure systems that are:
      • Producing ambiguous or conflicting definitions that cannot be mapped cleanly
      • Missing critical data required for key KPIs
      • So fragile that adding mapping logic elsewhere creates unacceptable risk

    When system upgrades are actually justified

    Upgrades or replacements become necessary when:

    • Data granularity is insufficient: For example, PLCs or SCADA only log binary “run/stop” events, but you need distinct reason codes and time categories for planned/unplanned stops, minor stops, changeovers, etc.
    • Time stamping and sequence accuracy are too poor: If the clocks, sampling rates, or buffering behavior make precise allocation of time losses impossible, some layer may need modernization.
    • Legacy systems are closed: If a critical system cannot expose its data at all, or only via manual exports, you may eventually need an upgrade or sidecar solution to support reliable, validated metrics.
    • Validation and change control are unmanageable: If workarounds and mappings become more complex than a controlled system upgrade, a targeted upgrade can actually reduce long-term compliance risk.

    Even in these cases, changes should be targeted, planned with minimal downtime, and justified by a clear link to metrics quality, regulatory expectations, or business impact. Full platform replacement purely for ISO 22400 alignment is rarely warranted in aerospace-grade or similar environments because of qualification burden, revalidation cost, and integration risk.

    Key constraints in regulated, long-lifecycle plants

    In regulated industries, “upgrade everything” is usually not viable because:

    • Validation and qualification: Each change to MES, SCADA, data models, or calculations can trigger revalidation, documentation updates, and potential re-training.
    • Traceability of metric definitions: You must be able to show how KPIs are defined, where each input comes from, and how changes were governed. This often favors leaving legacy systems stable and documenting mappings rather than changing every component.
    • Downtime and integration risk: Replacing multiple systems at once significantly increases the probability of prolonged downtime and integration defects that can corrupt or misalign metrics data.
    • Lifecycle and supplier constraints: Many control systems and equipment controllers have 10–20+ year lifecycles. Forcing upgrades purely for metric semantics can conflict with OEM support strategies or internal engineering bandwidth.

    Practical implementation pattern

    A pragmatic ISO 22400 implementation usually looks like this:

    • Establish a single, controlled specification for how ISO 22400 KPIs are calculated at your site or across sites.
    • Implement standardized calculations in a limited set of systems (for example, MES and an analytics/data platform).
    • Use integration, mapping, and business rules to translate legacy states, codes, and tags into the ISO 22400 model.
    • Upgrade or reconfigure individual systems only where mapping is not technically or operationally credible.
    • Maintain documentation and audit trails so that metric changes are visible and explainable during audits and investigations.

    In summary, ISO 22400 adoption is mostly a data, semantics, and governance problem, not a universal software upgrade mandate. The goal is consistent, traceable metrics across your brownfield environment, achieved through selective changes, controlled mappings, and careful validation.