Connect981 – Content Dev

Glossary Tag: process monitoring

  • Semantic KPI layer

    A semantic KPI layer is a business-facing definition layer that gives key performance indicators (KPIs) consistent meaning across data sources, applications, dashboards, and reports. It commonly defines how a KPI should be interpreted, calculated, named, filtered, and grouped so different users and systems refer to the same metric in the same way.

    In manufacturing and regulated operations, this layer often sits above raw data from MES, ERP, quality systems, historians, and other operational sources. It does not replace those source systems or the underlying transactional data. Instead, it organizes metric logic and business context so measures such as yield, scrap, downtime, first pass quality, or schedule adherence are calculated consistently.

    What it includes

    • Standard KPI definitions and naming conventions

    • Calculation logic, units, time windows, and aggregation rules

    • Business context such as plant, line, work center, product, shift, lot, or order dimensions

    • Data mappings that connect operational data fields to business terms

    • Governance elements such as ownership, approved formulas, and versioned changes

    What it does not mean

    A semantic KPI layer is not just a dashboard, a data warehouse, or a list of KPI names in a slide deck. Those may consume or display the layer, but the layer itself is the shared meaning and metric logic. It is also not the same as a general semantic data model for all enterprise data, although it may be implemented as part of one.

    Operational meaning

    Operationally, a semantic KPI layer helps align reporting between systems that track the same process differently. For example, an MES may record machine states, an ERP may record order completions, and a quality system may record nonconformances. The semantic KPI layer can define how those records contribute to metrics like OEE, throughput, rework rate, or right-first-time so downstream analytics use a common interpretation.

    This is especially relevant where KPI disputes arise from different formulas, timing assumptions, or data filters. A governed layer can document whether planned downtime is excluded, whether partial completions are counted, or which event codes roll up into a downtime category.

    Common confusion

    Semantic KPI layer vs. KPI dashboard: a dashboard presents metrics; the semantic layer defines what those metrics mean.

    Semantic KPI layer vs. data model: a data model structures data entities and relationships; a semantic KPI layer focuses on business meaning and reusable metric definitions, though the two often overlap.

    Semantic KPI layer vs. master data: master data manages core reference entities such as products or equipment; the semantic KPI layer uses those entities to define and contextualize performance measures.

  • operational baseline

    An operational baseline is a defined reference point for how a process, asset, production line, or system normally operates at a given time. It commonly includes the expected settings, conditions, performance ranges, and control context used to compare future operation against a known state.

    In manufacturing and regulated operations, an operational baseline may cover items such as standard cycle times, equipment parameters, approved process settings, expected throughput, normal alarm patterns, quality levels, or system configuration details. The exact content depends on what is being baselined: a machine, a production cell, a software environment, a plant utility system, or a broader operation.

    The term is descriptive, not necessarily fixed forever. A baseline can be revised when approved changes are made, but at any point in time it serves as the reference for detecting drift, assessing deviations, investigating issues, and evaluating whether current performance or configuration still matches the expected state.

    What it includes and excludes

    • Includes the documented or agreed normal state used for comparison.

    • Includes operational, technical, or performance attributes that are relevant to monitoring and control.

    • Excludes temporary conditions such as startup, shutdown, maintenance mode, or known abnormal events unless those are explicitly defined as separate baselines.

    • Excludes a target or aspiration by itself. A baseline is usually the current or validated reference state, not just a future goal.

    How it is used in practice

    Operational baselines are commonly used in daily management, process monitoring, quality review, and change control. For example, a plant may compare current machine performance against a baseline established after qualification, or compare current OT network traffic against a baseline of normal communications to identify unusual activity. In MES, ERP, historian, or monitoring environments, the baseline may be reflected in master data, approved recipes, version-controlled settings, or KPI thresholds.

    Common confusion

    Operational baseline is often confused with a performance target. A target states the desired result, while a baseline states the reference condition used for comparison.

    It can also be confused with a configuration baseline. A configuration baseline usually focuses on approved technical components, versions, or settings. An operational baseline is broader and may include how the process or system behaves in use, including expected operating ranges and performance patterns.

    In some contexts, people also use the term similarly to standard work or a golden batch, but those are narrower ideas. Standard work defines the approved method for performing tasks, and a golden batch refers to a model production run or parameter profile. An operational baseline may incorporate aspects of both without being limited to either one.

  • Leading Indicator

    A leading indicator is a measure that provides an early signal about conditions, behaviors, or process changes that may affect a future result. In manufacturing and regulated operations, it commonly refers to a metric used to monitor whether risk is building, controls are weakening, or performance is likely to change before a final outcome is visible.

    Leading indicators are different from outcome measures. They do not confirm that a defect, delay, deviation, or downtime event has already happened. Instead, they track upstream factors that may influence those results. Examples can include missed process checks, rising alarm frequency, training completion gaps, overdue maintenance tasks, repeated parameter drift, or increasing rework trends at an intermediate step.

    How it is used in operations

    In day-to-day workflows, a leading indicator is often used in dashboards, shift reviews, quality monitoring, maintenance planning, or continuous improvement programs. It helps teams watch process stability and execution discipline rather than only reviewing end-of-line results. In connected systems, leading indicators may be sourced from MES, ERP, QMS, CMMS, historian data, or manual audit records.

    A useful leading indicator is usually:

    • observable before the final outcome occurs
    • connected to a process, control, or behavior that can change over time
    • tracked consistently enough to show trend movement
    • specific enough to support investigation without being mistaken for proof of a future event

    What it includes and excludes

    The term includes predictive or early-warning measures tied to process conditions, compliance execution, maintenance health, workforce readiness, or quality risk. It can be quantitative, such as the rate of skipped inspections, or qualitative, such as recurring audit observations when those observations are tracked consistently.

    It does not mean a guaranteed predictor. A leading indicator suggests direction or elevated likelihood, not certainty. It also does not mean any metric collected early in a process. If a measure has no meaningful relationship to later outcomes, it is not a useful leading indicator even if it is available sooner.

    Common confusion

    Leading indicator vs lagging indicator: A leading indicator signals conditions that may influence future performance. A lagging indicator reports a result that has already occurred, such as scrap rate, on-time delivery, or number of nonconformances closed.

    Leading indicator vs KPI: A KPI is a broader term for an important performance measure. Some KPIs are leading indicators, some are lagging indicators, and some combine both.

    Leading indicator vs alarm: An alarm is an immediate notification about a threshold or event. A leading indicator is a metric or trend used to assess developing conditions over time, although alarms can feed into one.

    Manufacturing example

    If final defect rate is increasing only after product reaches inspection, that defect rate is a lagging indicator. If torque exceptions, skipped verifications, and tool calibration overdue counts begin rising earlier in the routing, those measures may serve as leading indicators of future quality issues.

  • KPI council

    A KPI council commonly refers to a cross-functional governance group responsible for overseeing key performance indicators, including how KPIs are defined, calculated, reviewed, and changed over time. In manufacturing and regulated operations, it often exists to keep performance reporting consistent across functions such as production, quality, maintenance, supply chain, and finance.

    It is not a KPI itself, and it is not just a reporting meeting. The term usually describes a standing forum or decision body that manages KPI ownership, data definitions, thresholds, review cadence, and escalation rules. Depending on the organization, it may be formal with documented charters and approval workflows, or informal but still used as the place where metric disputes and updates are resolved.

    How it is used in operations

    In operational settings, a KPI council often reviews questions such as:

    • Which KPIs are official and who owns them
    • How each KPI is calculated and from which systems the data is sourced
    • Whether plant, line, shift, supplier, or enterprise views use the same definitions
    • How targets, thresholds, and exception rules are set
    • What to do when ERP, MES, QMS, or manual reports show conflicting values

    For example, a KPI council may decide whether first-pass yield, on-time delivery, scrap rate, or schedule adherence should be measured at the work center, work order, or site level, and which source system is considered authoritative for each metric.

    What it includes and excludes

    A KPI council usually includes governance activities around metric standardization, review, and change control. It may also support metric rationalization, meaning the removal of duplicate or low-value measures.

    It does not usually perform day-to-day data entry, direct production execution, or root cause analysis itself, although it may trigger those activities when KPI results indicate an issue.

    Common confusion

    KPI council is sometimes confused with a daily management meeting, performance review meeting, or steering committee. A daily management meeting focuses on current performance and immediate actions. A KPI council focuses more on metric governance, consistency, and lifecycle management. It may also be confused with a data governance council. A data governance council usually has a broader scope that covers master data, data quality, access, and policies beyond performance metrics.

    In system and reporting contexts

    Where MES, ERP, QMS, historian, or analytics platforms are integrated, a KPI council often helps define the official business meaning of metrics so dashboards and reports use the same logic across systems. This is especially relevant when the same operational signal can be calculated differently by different applications or departments.

  • MRO turnaround time

    MRO turnaround time commonly refers to the total elapsed time from when a repairable asset, component, or unit enters an MRO process until it is returned to service, shipped back, or otherwise made available for use again. In industrial and aerospace contexts, it is usually measured in calendar time or working time across the full maintenance, repair, and overhaul cycle.

    The term includes more than hands-on repair time. It often covers receiving, inspection, diagnosis, disassembly, waiting for parts, repair or replacement activity, testing, documentation, approvals, packaging, and release. Depending on how an organization defines the metric, transportation time before intake or after release may be included or excluded, so the start and end points should be stated clearly.

    What it includes

    • Intake and receiving of the asset or part
    • Evaluation, troubleshooting, or teardown
    • Repair, overhaul, replacement, or rework steps
    • Internal queues, hold time, and waiting for parts or approvals
    • Inspection, test, and final release activities
    • Administrative closeout and return to stock, customer, or operation

    What it is not

    MRO turnaround time is not the same as pure repair labor hours, wrench time, or machine runtime. It is also not automatically the same as manufacturing lead time for a new product, although both are elapsed-time measures. In many organizations, it is a service-cycle metric for maintainable assets rather than a production-cycle metric for newly built items.

    Operational meaning

    In workflows and enterprise systems, MRO turnaround time is often tracked across work orders, maintenance events, depot repair jobs, or service orders. It may be used to understand backlog, capacity loading, parts delays, approval bottlenecks, and release performance. ERP, MES, EAM, or specialized MRO systems may record timestamps for receipt, induction, repair stages, test completion, and final closure to calculate the metric.

    For example, a hydraulic actuator received on Monday, inspected on Tuesday, held for parts until Thursday, repaired on Friday, tested the next Monday, and shipped on Tuesday would have a turnaround time that reflects the full elapsed interval, not just the bench repair activity.

    Common confusion

    MRO turnaround time is commonly confused with cycle time, lead time, and time to repair. Cycle time often refers to the duration of a specific process step or active operation. Lead time can be broader and may include customer request, procurement, and logistics stages outside the repair cell. Time to repair usually focuses more narrowly on the technical repair task itself. In maintenance settings, turnaround time is usually the end-to-end elapsed duration for returning the item to usable status.

  • First time yield

    First time yield commonly refers to the percentage of units, assemblies, or process steps that pass through a manufacturing process correctly on the first attempt, without needing rework, repair, retest, or scrap handling before moving forward. It is used as a quality and process performance measure in production, test, inspection, and packaging workflows.

    In practical terms, first time yield shows how often work is done right the first time at a defined point in the process. Depending on how an organization measures it, the denominator may be all units started at an operation, all units completed, or all opportunities at a specific step. Because calculation methods vary, the exact formula should be defined locally when comparing lines, plants, suppliers, or reporting periods.

    What it includes and excludes

    First time yield usually includes output that meets requirements at the initial pass of a process step or route. It generally excludes units that only pass after correction activities such as rework, adjustment, troubleshooting, retest, or repair.

    • Includes: conforming output accepted on the initial run through a defined operation or sequence
    • Excludes: parts or lots that require rework, repair, deviation handling, or repeated testing before acceptance

    Some organizations also exclude scrapped units entirely, while others count them as failed first-pass attempts. That difference can materially change reported values.

    How it appears in operations

    First time yield is commonly tracked in MES, quality systems, test systems, or production reporting dashboards. It may be measured at several levels, such as a single work center, a test station, a routing step, a production line, or an end-to-end build process.

    Examples in manufacturing include a board that passes electrical test on its first run, a machined part that meets dimensional requirements without rework, or a batch record step completed without correction.

    Common confusion

    First time yield is often confused with first pass yield. In many organizations the terms are used interchangeably, but some teams define first pass yield more narrowly for one station or inspection point, while first time yield may refer to a broader process or completed workflow. The terms should not be assumed to be identical unless the local definition is stated.

    It is also different from rolled throughput yield, which combines yields across multiple sequential steps to show the probability that a unit moves through an entire process without defects or rework.

  • APQP (Advanced Product Quality Planning)

    APQP commonly refers to Advanced Product Quality Planning, a structured method for planning and coordinating the activities needed to bring a new product or changed product into production with defined quality controls. It is used to organize cross-functional work across product design, process design, risk review, validation, supplier inputs, and production readiness.

    In manufacturing, APQP is not a single form, software module, or inspection step. It is a planning framework that links product requirements to process definition, control methods, and evidence generated before and during launch. It is most often associated with automotive supply chains, but the underlying approach is also relevant in other regulated or quality-sensitive manufacturing environments where design transfer and production readiness need to be controlled.

    What APQP includes

    • Planning product and process requirements before production release

    • Coordinating activities across engineering, quality, manufacturing, supply chain, and suppliers

    • Identifying risks and special controls early in development and industrialization

    • Defining validation and readiness activities such as process capability, measurement planning, and production trial outputs

    • Creating the records and deliverables used to show that the product and process were prepared for launch

    In practice, APQP often connects to documents and workflows such as design reviews, process flow diagrams, PFMEA, control plans, MSA, capability studies, PPAP-related outputs, and launch checklists. The exact deliverables can vary by industry, customer, and internal quality system.

    What APQP does not mean

    APQP does not mean final product approval by itself, and it is not the same as PPAP. APQP covers the broader planning and execution process that leads up to production readiness, while PPAP commonly refers to a submission package or approval process used to demonstrate that readiness. APQP is also not equivalent to project management in general, although project management methods are often used to track APQP activities.

    How it appears in operations and systems

    Operationally, APQP appears as a staged set of quality planning tasks tied to product introduction, engineering change, supplier qualification, or process transfer. In digital environments, these activities may be distributed across PLM, QMS, ERP, MES, and supplier collaboration systems. For example, product characteristics may originate in design systems, risk and control definitions may be managed in quality records, and production validation evidence may be captured from shop floor or supplier processes.

    APQP is often used to create alignment between design intent and manufacturing execution by making sure required controls, inspection methods, documentation, and release criteria are defined before routine production begins.

    Common confusion

    APQP is commonly confused with:

    • PPAP: PPAP is typically the evidence or submission process used to demonstrate that product and process requirements have been met. APQP is the broader planning framework.

    • Control Plan: A control plan is usually one APQP output, not the full APQP process.

    • PFMEA: PFMEA is a risk analysis tool often used within APQP, not a synonym for APQP.

    • NPI or product launch: New product introduction and launch management are broader business processes. APQP is the quality planning discipline within that broader effort.

  • operational visibility

    Operational visibility commonly refers to the ability to see, understand, and track what is happening across an operation as work is planned, executed, measured, and escalated. In manufacturing and regulated environments, it usually includes timely access to information about production status, materials, equipment, labor, quality events, and workflow conditions.

    It is not limited to a single dashboard or report. It depends on the availability, context, and reliability of operational data across systems such as MES, ERP, quality systems, maintenance platforms, shop floor devices, and connected machines. The term usually implies that people can view the state of operations clearly enough to recognize progress, delays, exceptions, and emerging risks.

    What it typically includes

    • Status of orders, batches, jobs, or work orders

    • WIP location and flow through routing steps

    • Equipment state, downtime, alarms, or utilization signals

    • Material availability, shortages, and staging status

    • Quality checks, holds, nonconformances, and rework status

    • Shift performance, bottlenecks, and schedule variance

    • Traceability-related context such as lot, serial, or genealogy data when relevant

    Depending on the organization, operational visibility may be near real time, shift-based, or based on periodic synchronization between systems. It does not necessarily mean full automation or a complete digital thread.

    How it appears in practice

    In day-to-day operations, operational visibility often shows up through dashboards, escalation boards, status views, alerts, exception queues, and reports that combine data from multiple sources. For example, a supervisor may use it to see which work orders are stalled, which machines are down, or which lots are on quality hold. A planner may use it to see whether material shortages or labor constraints are affecting schedule adherence.

    In regulated manufacturing, the term can also extend to visibility into controlled records and evidence trails, but it is not the same as document control, audit readiness, or compliance management.

    Common confusion

    Operational visibility is often confused with traceability. Traceability focuses on the historical record of where a product, material, or action came from and where it went. Operational visibility focuses more broadly on the current and recent state of operations.

    It is also commonly confused with observability. In software and infrastructure contexts, observability usually refers to the ability to infer system behavior from logs, metrics, and traces. Operational visibility is broader and more business-process-oriented in manufacturing.

    Another related term is performance management. Performance management uses metrics and targets to assess outcomes. Operational visibility is the underlying ability to see the signals and conditions that inform those assessments.