Connect981 – Content Dev

Glossary Tag: process monitoring

  • Legacy KPI

    A legacy KPI is a key performance indicator that has been carried over from earlier processes, systems, or organizational strategies and continues to be tracked, even when its relevance to current operations may be limited.

    What it typically includes

    In industrial and regulated manufacturing environments, legacy KPIs commonly refer to metrics that:

    • Originated from previous production methods, reporting practices, or management priorities
    • Are embedded in historical reports, dashboards, or MES/ERP configurations
    • Continue to be collected and displayed because they are familiar or easy to calculate
    • May not clearly support current quality, compliance, cost, or delivery objectives

    Examples include:

    • A machine utilization percentage defined using outdated shift patterns, no longer aligned with current scheduling
    • A defect rate metric that excludes new product families or process steps introduced after the KPI was first defined
    • A manual data collection KPI that persists even after the same information is available through integrated OT/IT systems

    How it shows up operationally

    Legacy KPIs often appear in:

    • Standard production or quality reports that have not been recently reviewed
    • MES, historian, or BI dashboards where old data views were migrated unchanged
    • Management review packs and audit evidence binders that use historic metric definitions

    Operations and quality teams may continue to collect and discuss these KPIs without clear linkage to current strategic metrics such as OEE, NPT, or cost of poor quality.

    Why the distinction matters

    Identifying a KPI as a legacy KPI does not automatically mean it is wrong or should be removed. The term highlights that:

    • The metric definition was created for a past context and should be revalidated
    • The calculation logic, data sources, and thresholds may not match present-day processes or regulatory expectations
    • The KPI may duplicate information available in newer, better-aligned metrics

    Common confusion

    • Legacy KPI vs. obsolete KPI: A legacy KPI is inherited from the past. It becomes obsolete only when it is intentionally retired or no longer used for decisions.
    • Legacy KPI vs. lagging KPI: A lagging KPI measures outcomes after they occur (for example, monthly defect rate). A legacy KPI is about historical origin and relevance, not the timing of measurement.

    Relation to performance and compliance

    In regulated environments, legacy KPIs may remain part of documented management review or quality system records. When processes, equipment, or information flows change, organizations commonly reassess whether legacy KPIs should be:

    • Retained with updated definitions and data sources
    • Mapped to new performance frameworks (for example, aligned with OEE or CAPA indicators)
    • Archived as historical metrics and removed from routine reporting

    This review helps keep operational performance measurement consistent with current manufacturing reality and documented procedures.

  • ECN

    An ECN, or Engineering Change Notice, is a controlled document used to propose, review, approve, and communicate engineering or design changes to a product, component, or manufacturing process. It is a core element of formal change control in regulated and industrial manufacturing environments.

    What an ECN includes

    While formats vary by organization, an ECN commonly includes:

    • Identification of the affected items (part numbers, drawings, specifications, BOMs, routings, software, tools)
    • Current revision and proposed new revision or configuration
    • Description of the change and rationale (e.g., quality, cost, performance, obsolescence)
    • Impact assessment on form/fit/function, compliance, tooling, documentation, and inventory
    • Required updates in related systems (PLM, ERP, MES, QMS, work instructions, FAI/AS9102 records)
    • Disposition instructions for in-process and finished product (use-as-is, rework, scrap, effective date)
    • Approvals from engineering, quality, operations, supply chain, and other stakeholders

    How ECNs are used operationally

    In practice, ECNs connect design changes to operational execution:

    • Origination and authoring typically occur in PLM or an engineering document control system.
    • Once approved, the ECN drives updates to drawings, CAD models, specifications, and BOMs.
    • Revisions and effectivity from the ECN are propagated to ERP, MES, and shop-floor systems so that work orders, routings, and digital travelers use the correct version.
    • Quality systems reference ECNs when updating control plans, inspection plans, FAI baselines, and AS9102 packages.
    • Suppliers may receive ECN notifications so they can transition to the new revision under controlled conditions.

    Scope and boundaries

    An ECN:

    • Covers defined changes to the design definition or engineering-controlled documents.
    • Is part of a broader change-control framework that can include related records such as ECOs, deviations, concessions, or waivers.
    • Does not by itself guarantee that downstream systems are synchronized; integration and governance are required to align PLM, ERP, MES, and FAI tools.

    Common confusion

    • ECN vs ECO (Engineering Change Order): Some organizations use ECN and ECO interchangeably. Others distinguish them, for example treating the ECN as the notification/summary of a change and the ECO as the formal order that implements it. Usage is company-specific.
    • ECN vs ECR (Engineering Change Request): An ECR typically initiates or requests a change and may be more exploratory. An ECN is usually created once a specific change is defined and ready for formal review and implementation.
    • ECN vs NCR/CAPA: Nonconformance and corrective action records address quality issues and their resolution. ECNs may be one of the actions taken to permanently change the design or process in response to issues surfaced by NCRs or CAPAs, but they are different record types.

    Ties to drawing and FAI revision control

    In environments using PLM and First Article Inspection (FAI) tools, ECNs are often the authoritative mechanism for changing drawing revisions that FAI and AS9102 records reference. Reliable synchronization of part numbers, revisions, and effectivity dates across PLM, ERP, MES, and FAI systems depends on clear ECN governance, consistent keys (part and revision), and well-defined data flows.

  • Context dimension

    A context dimension is a descriptive category used to add meaning to data, events, records, or process states by identifying the circumstances in which they occur. In manufacturing and industrial systems, it commonly refers to a field or attribute that helps users group, filter, compare, or interpret operational information.

    Examples of context dimensions include time, site, area, line, machine, product, batch, shift, operator, work order, material lot, supplier, and reason code. These dimensions do not usually represent the measured value itself. Instead, they provide the surrounding business or operational context for that value.

    How it is used in operations and systems

    In MES, ERP, quality, historian, and analytics environments, a context dimension helps organize records so that the same signal or transaction can be analyzed from different perspectives. For example, downtime minutes may be measured as a value, while line, shift, product family, and cause code act as context dimensions that explain where and under what conditions the downtime happened.

    Context dimensions are often used in:

    • reporting and dashboard filters
    • trend analysis and KPI breakdowns
    • traceability and genealogy views
    • nonconformance and deviation records
    • alarm, event, and exception analysis
    • data models that connect OT and IT systems

    What it includes and excludes

    A context dimension usually includes stable descriptive attributes that can classify or slice information consistently across records. It may be master data driven, transaction driven, or derived from system structure.

    It does not usually mean the metric, fact, or outcome being measured. For example, yield percentage, cycle time, and defect count are measures, not context dimensions. A context dimension also is not the same as free-text commentary, although comments may add context in a general sense.

    Common confusion

    Context dimension is commonly confused with measure or KPI. A measure is the numeric or categorical result being tracked, while a context dimension explains how that result can be segmented or interpreted.

    It can also be confused with metadata. Metadata is a broader term for data about data. A context dimension is a more specific analytical or operational attribute used to classify records in a meaningful way.

    In some software and analytics disciplines, similar concepts may be called dimensions, attributes, tags, qualifiers, or categorical fields. The exact label varies by system, but the core idea is the same: adding structured context so information can be understood and analyzed correctly.

  • use-as-is

    In regulated manufacturing and aerospace, use-as-is is a formal nonconformance disposition that allows a part, assembly, or product to be accepted and released without restoring full conformance to the original specification or drawing, provided it is judged acceptable for its intended use.

    What use-as-is includes

    Use-as-is disposition typically means:

    • The nonconformance is documented on a nonconformance report (NCR) or similar record.
    • Technical authorities (often quality, engineering, and sometimes the design or customer authority) have reviewed the deviation.
    • The part or product is determined to be functionally acceptable, safe for its intended application, and compatible with system performance requirements.
    • No rework or repair will be performed to bring it back exactly to the original specification, although minor administrative updates (such as records or markings) may still occur.

    What use-as-is does not include

    Use-as-is does not mean:

    • Ignoring or hiding the nonconformance.
    • Automatically accepting all deviations without engineering or quality review.
    • Rework or repair actions to change the physical condition of the item (those are separate dispositions).
    • A permanent design change. If the design itself is updated, that is handled through configuration or change control, not just a use-as-is decision.

    Operational context in manufacturing

    In production environments, especially aerospace, defense, automotive, and other regulated sectors, use-as-is is one of several standard dispositions on an NCR, alongside options such as rework to specification, repair, or scrap. MES, QMS, and ERP systems often implement use-as-is as a selectable code or status, tied to workflows for:

    • Routing the NCR to appropriate approvers (e.g., quality, design engineering, customer or regulatory representative).
    • Recording justifications, risk assessments, and any conditional limitations (for example, limited life, restricted application, or traceability notes).
    • Linking the disposition to affected serial numbers, lots, or work orders for traceability.

    Common confusion

    • Use-as-is vs. rework to spec: Rework to spec involves processing the item so it fully meets the original requirements. Use-as-is accepts the deviation without restoring full conformance.
    • Use-as-is vs. repair: Repair typically introduces a controlled deviation from the original design (often requiring specific repair instructions). Use-as-is does not change the item further; it accepts the current condition.
    • Use-as-is vs. waiver/deviation: A waiver or deviation is a formal authorization to depart from a requirement. A use-as-is disposition may rely on a waiver or deviation, but the terms are not identical. Waiver/deviation refers to the requirement; use-as-is refers to how the specific nonconforming item is handled.

    Link to aerospace NCR processes

    In aerospace, use-as-is dispositions often require approval from quality and design engineering, and sometimes from the customer or regulatory design authority, depending on configuration control, contract terms, and the criticality of the nonconforming feature. Local procedures define who is authorized to approve use-as-is and how such decisions are documented for audit and traceability.

  • KPI documentation

    KPI documentation is the controlled set of records that define, explain, and govern how key performance indicators (KPIs) are selected, calculated, visualized, and maintained within an organization. In industrial and regulated manufacturing environments, it provides a common reference so that performance metrics are interpreted consistently across sites, systems, and functions.

    What KPI documentation typically includes

    Although formats vary, KPI documentation commonly contains:

    • Metric definition: name of the KPI, a clear description, and its purpose (for example, on-time delivery, scrap rate, OEE).
    • Calculation logic: formulas, time basis (shift, day, batch), data sources (MES, ERP, QMS), inclusion/exclusion rules, and handling of rework or special cases.
    • Data ownership and responsibilities: who maintains the KPI definition, who validates data quality, and who reviews the results (e.g., production, quality, supply chain).
    • Collection and reporting method: how data is captured (manual entry, automated tags, integrations), where KPIs are displayed (dashboards, reports), and update frequency.
    • Scope and boundaries: which plants, product families, work centers, or suppliers are covered, and any explicit exclusions.
    • Governance and revision history: approval paths, effective dates, change history, and links to supporting procedures or standards.

    Role in industrial and regulated environments

    In manufacturing settings, KPI documentation helps align how operational performance is measured across OT and IT systems. For example, it can specify whether downtime events from an MES are categorized as planned or unplanned, or how nonconformances from a QMS feed yield and cost of poor quality KPIs. In regulated sectors, documented KPI definitions can also support audit readiness by showing that metrics used in management review, continuous improvement, or supplier monitoring are consistently defined and controlled.

    Operational use

    On a day-to-day basis, KPI documentation is used to:

    • Configure dashboards and reports in MES, ERP, or analytics tools according to approved formulas and filters.
    • Onboard new engineers, supervisors, and analysts so they interpret metrics such as OEE, NPT, or on-time delivery in the same way.
    • Support problem-solving and continuous improvement by making clear how changes on the shop floor will affect specific KPIs.
    • Provide evidence during internal or external reviews that performance metrics are based on traceable, governed definitions.

    Common confusion

    • KPI documentation vs. KPI dashboard: A dashboard is the visual output that shows KPI values. KPI documentation describes how those values are defined and calculated. Dashboards should be configured to match the documented definitions.
    • KPI documentation vs. procedures or work instructions: Procedures and work instructions describe how work is performed. KPI documentation describes how performance of that work is measured. They are related but serve different purposes.

  • Workflow Configuration

    Workflow configuration commonly refers to the definition and setup of how a process moves through its steps in a software system or digital operation. It includes the rules, sequence, decision points, assignments, statuses, notifications, and data conditions that determine how work is created, routed, reviewed, approved, completed, or escalated.

    In manufacturing and regulated environments, workflow configuration often appears in MES, QMS, ERP-connected applications, document control systems, training systems, maintenance platforms, and nonconformance or CAPA processes. Examples include configuring approval paths for deviations, routing electronic work instructions by part or revision, assigning review tasks by role, or triggering holds when required data is missing.

    The term usually refers to setting up process logic inside a system, not performing the work itself. It also does not necessarily mean custom software development. Many platforms support workflow configuration through forms, business rules, status models, permissions, and low-code or no-code tools.

    What it typically includes

    • Process steps and status transitions

    • Role-based assignments and approvals

    • Entry and exit criteria for each stage

    • Business rules, validations, and conditional routing

    • Notifications, alerts, and escalation logic

    • Required records, attachments, or electronic signoffs

    • Links to master data, documents, equipment, or transactions in other systems

    Operational meaning

    Operationally, workflow configuration determines how a digital process behaves day to day. It affects who sees a task, what information is required, when a record can move forward, and what downstream actions are triggered. In integrated environments, workflow configuration may also govern handoffs between systems, such as sending order data from ERP to MES or moving quality events into CAPA review.

    Common confusion

    Workflow configuration is often confused with workflow design, process mapping, and software customization.

    • Workflow design defines the intended business process conceptually.

    • Workflow configuration implements that process behavior within a specific system.

    • Process mapping documents the flow, but does not by itself make the system enforce it.

    • Customization or development changes application code, while configuration usually uses built-in platform capabilities.

    The exact boundary varies by software platform, since some vendors use configuration to describe both rule setup and certain low-code extensions.

  • Boundaries and Applicability

    Boundaries and Applicability commonly refers to the explicit definition of what a system, process, requirement, or assessment covers, where it applies, and what is out of scope. In industrial and regulated manufacturing environments, it is used to avoid ambiguity about responsibilities, system coverage, and regulatory obligations.

    Core meaning

    When organizations describe boundaries and applicability, they are usually addressing two related questions:

    • Boundaries: The scope limits of something, such as a production process, OT/IT system, quality procedure, or risk assessment. This often includes which sites, lines, products, data flows, or functions are included or excluded.
    • Applicability: The situations, conditions, or entities to which a requirement, standard, control, or procedure applies. This may reference product families, process steps, regulatory classifications, or system configurations.

    Together, boundaries and applicability clarify the domain in which certain rules, controls, or behaviors are expected, and where they are not.

    Operational context in manufacturing

    In industrial and regulated settings, boundaries and applicability are typically documented in:

    • Quality and compliance procedures: Defining which plants, product ranges, or process variants a SOP covers, and which are explicitly excluded.
    • MES/ERP and OT/IT system descriptions: Stating which production areas, equipment, data types, and interfaces are within the scope of a system implementation or change, and which remain out of scope.
    • Risk, safety, and cybersecurity assessments: Describing the physical and logical boundaries of the system or process being analyzed, and the assets, networks, and users to which controls apply.
    • Regulatory and standards alignment: Explaining when specific regulatory requirements or industry standards apply to a product, process, or site based on criteria such as market, classification, or customer requirements.

    Clear boundaries and applicability help avoid overlap or gaps between systems and procedures, reduce conflicting instructions, and support consistent application of controls and records across sites and lines.

    What it typically includes

    Well defined boundaries and applicability statements often specify:

    • Physical scope: Sites, buildings, areas, production lines, equipment, or utilities.
    • Organizational scope: Departments, roles, or functions responsible or affected.
    • Process and product scope: Process steps, product families, variants, or batches covered.
    • System and data scope: Applications, interfaces, data types, and environments (e.g., test vs production).
    • Temporal scope: When the definition applies, such as effective dates or lifecycle phases.
    • Explicit exclusions: Items or situations that are intentionally left outside the scope.

    Common confusion

    • Scope vs. boundaries and applicability: “Scope” is often used as a single word for what is covered. “Boundaries and applicability” is a more explicit way to describe scope limits (boundaries) and the conditions or entities to which something applies (applicability).
    • Requirements vs. applicability: A requirement describes what must be done; applicability describes when, where, or to whom that requirement is relevant.

    Use in documentation and audits

    In procedures, system descriptions, validation packages, and risk assessments, a dedicated section on boundaries and applicability is often used to:

    • Clarify which operations and systems are covered by the document or activity.
    • Support consistent interpretation during internal reviews and external audits.
    • Provide a reference when evaluating change impact, nonconformances, or deviations.

    This term is descriptive and does not imply any specific standard or regulatory framework, but it is commonly used in quality systems, safety management, and OT/IT governance documentation.

  • cloud service provider

    A cloud service provider is an organization that delivers computing resources over a network from shared cloud infrastructure. These resources can include servers, storage, databases, networking, applications, and security services that customers access remotely rather than operating on their own on-premises hardware.

    Scope and types of cloud service providers

    In industrial and manufacturing environments, cloud service providers commonly offer:

    • Infrastructure as a Service (IaaS): Virtual machines, storage, and networking used to host MES, data historians, or analytics platforms.
    • Platform as a Service (PaaS): Managed databases, event streams, and application platforms used to build custom manufacturing or quality applications.
    • Software as a Service (SaaS): Hosted applications such as quality management systems, electronic logbooks, maintenance systems, or production analytics tools.

    The provider owns and operates the underlying data centers, hardware, and core software platforms, and is responsible for base-level security, availability, and capacity of those services. Customers retain responsibility for how they configure, use, and validate those services within their regulated manufacturing processes.

    Operational meaning in regulated manufacturing

    In regulated industrial operations, a cloud service provider typically:

    • Hosts production, quality, engineering, and supply chain applications or data services used by plants and corporate teams.
    • Implements technical controls such as identity and access management, logging, encryption, and network segregation.
    • Provides audit logs, configuration options, and documentation that customers may use as part of their own validation, cybersecurity, and compliance programs.
    • May align with reference frameworks (for example, FedRAMP baselines or similar security programs) without removing the customer’s need for plant-level validation, integration testing, and supplier oversight.

    Cloud service providers are usually managed as critical suppliers or vendors, with contracts, service-level expectations, and security assessments governed by the manufacturer’s supplier management process.

    Common confusion

    • Cloud service provider vs. SaaS vendor: A SaaS vendor delivers a specific application over the cloud. That vendor may itself rely on another underlying cloud service provider for infrastructure.
    • Cloud service provider vs. hosting provider: Traditional hosting providers may offer fixed servers with limited self-service capabilities. Cloud service providers generally offer elastic, programmable infrastructure and standardized services (APIs, managed databases, etc.).

    Relation to security frameworks such as FedRAMP

    Some cloud service providers offer services that align with government or industry security frameworks. In manufacturing, these services are often selected for handling sensitive technical data, production records, or quality documentation. Such alignment usually indicates a defined set of security and control practices at the provider level, but it does not, by itself, establish compliance for a specific plant, product, or process. Organizations still need to perform their own risk assessments, validation, and ongoing oversight of the provider.

  • data latency

    Data latency commonly refers to the time delay between when an event happens in the real world (for example on the shop floor or in a machine) and when trustworthy data about that event is available to users, dashboards, or downstream systems. In industrial and manufacturing environments, it is the lag between a production, quality, maintenance, or inventory change and when that change is reflected in MES, ERP, historians, or reporting tools.

    How data latency shows up in manufacturing

    In regulated and complex plants, data latency can occur at several layers:

    • Acquisition latency: Delay between a physical event and the signal being captured by a sensor, PLC, or device.
    • Transmission latency: Delay while data moves over networks from OT devices to SCADA, historians, MES, or cloud services.
    • Processing latency: Time required for systems to clean, contextualize, aggregate, and store data (for example, mapping tags to equipment, products, and lots).
    • Integration latency: Delay introduced by batch interfaces between systems such as MES, ERP, QMS, LIMS, and maintenance systems.
    • Presentation latency: Delay between data being stored and when dashboards, reports, or alerts are refreshed.

    Operationally, data latency affects how “real time” production visibility dashboards, OEE calculations, quality monitors, and inventory views actually are. High latency can mean supervisors, planners, and quality teams are making decisions based on outdated data, even if dashboards appear live.

    Data latency versus related concepts

    • Data latency vs. throughput: Latency is about timing (how long a single data point takes to become visible). Throughput is about volume (how many data points per unit of time a system can handle).
    • Data latency vs. sampling rate: Sampling rate is how often data is captured. Latency is the delay before captured data becomes available to use. A high sampling rate can still have high latency if processing and integration are slow.
    • Data latency vs. data quality: Latency is about delay; data quality is about correctness and completeness. Low latency data can still be inaccurate if it is not validated or contextualized.

    Common confusion

    Data latency is sometimes loosely called “real-time” or “near real-time” performance. In practice, these terms are relative and depend on the process. For high-speed automated lines, seconds of latency can matter. For planning processes driven by ERP batch jobs, latency may be measured in minutes or hours. It is also sometimes confused with network latency alone, but in manufacturing environments most delay often comes from processing, integration, and refresh cycles rather than pure network transport.

    Link to production visibility dashboards

    When implementing production visibility dashboards, data latency determines whether displayed KPIs, alarms, and trends represent current operations or a delayed snapshot. Latency may come from slow queries against MES/ERP, overnight batch integrations, or manual data entry cycles. Understanding and documenting expected data latency is important so users interpret dashboards correctly and do not assume they are fully real time when they are not.

  • IT–OT convergence

    IT–OT convergence commonly refers to the intentional integration and coordination of information technology (IT) systems with operational technology (OT) systems in industrial and manufacturing environments. It focuses on treating business information systems and plant-floor control systems as a connected ecosystem rather than separate technology stacks.

    What IT–OT convergence includes

    In regulated and industrial operations, IT–OT convergence typically includes:

    • Connecting enterprise IT systems (such as ERP, PLM, LIMS, and quality systems) with plant-floor OT systems (such as PLCs, DCS, SCADA, historians, and MES).
    • Aligning data models, standards, and interfaces so production, quality, maintenance, and business data can be exchanged and used consistently.
    • Coordinating governance, cybersecurity policies, and change control across both IT and OT environments.
    • Implementing shared architectures and platforms, for example using industrial networks, edge computing, and secure gateways to bridge plant and enterprise networks.
    • Defining joint roles and responsibilities for IT and OT teams, including support, incident response, and lifecycle management for shared systems.

    IT–OT convergence is not a single product or standard. It is a combination of architecture, integration approaches, and organizational practices that connect technology and data across traditional IT and OT boundaries.

    Operational meaning in manufacturing

    At an operational level, IT–OT convergence shows up in activities such as:

    • Integrating MES and ERP so production orders, material data, and quality results flow automatically between business and shop-floor systems.
    • Streaming data from sensors, controllers, and historians into analytics, reporting, and operations-intelligence platforms managed by IT.
    • Applying unified access control, patching, backup, and monitoring practices to both servers in the data center and industrial devices on the plant floor, with appropriate OT-specific constraints.
    • Supporting traceability and genealogy requirements by combining equipment event data with batch records, electronic device history records, or electronic batch records.

    Common confusion

    IT–OT convergence is often discussed alongside related concepts:

    • Industry 4.0 / smart manufacturing: IT–OT convergence is one enabling aspect of these initiatives but is more specific, focusing on how IT and OT systems and teams connect and collaborate.
    • IIoT (Industrial Internet of Things): IIoT emphasizes connected devices and data collection. IT–OT convergence is broader and includes governance, organizational integration, and enterprise-to-plant processes, not just device connectivity.
    • Network convergence: Combining IT and OT networks is one technical element of IT–OT convergence, but the term also covers applications, data, security practices, and organizational alignment.

    Relevance in regulated and compliant environments

    In regulated manufacturing, IT–OT convergence is closely linked to topics such as:

    • Data integrity and consistent handling of electronic records across enterprise and plant-floor systems.
    • Coordinated cybersecurity controls for both IT and OT assets, often aligned with industrial security standards.
    • Change management and validation practices that span MES, ERP, control systems, and interfaces between them.
    • Audit readiness, where evidence may rely on data and logs from both IT and OT systems.

    When planned and governed appropriately, IT–OT convergence provides a structured way to treat industrial control systems and enterprise information systems as parts of a single, managed operational ecosystem.