Connect981 – Content Dev

Glossary Tag: process monitoring

  • Residual Risk

    Residual risk commonly refers to the level of risk that remains after all reasonably practicable controls, safeguards, and mitigations have been identified, implemented, and verified. In other words, it is the risk that is still present even after a manufacturer has applied its risk-reduction measures.

    In industrial and manufacturing environments

    In regulated manufacturing and industrial operations, residual risk is typically evaluated as part of formal risk management or hazard analysis processes. It appears in activities such as:

    • Equipment and process safety assessments (for example, machinery hazards, chemical handling, or automated line risks)
    • Quality risk management for products and processes (for example, risk of nonconforming product reaching customers)
    • Information security and OT/IT cybersecurity risk assessments
    • Data integrity and compliance risk analysis for MES, ERP, LIMS, and other regulated systems

    Operationally, residual risk is often documented in risk registers, Failure Mode and Effects Analyses (FMEAs), hazard analyses, or cybersecurity risk assessments. Each identified risk typically has:

    • Inherent risk: estimated before any controls are applied
    • Controls and mitigations: preventive, detective, and corrective safeguards
    • Residual risk: re-estimated after considering the effectiveness of those controls

    Residual risk is usually compared against an organization’s defined risk acceptance criteria. If the residual risk is above the acceptable level, further controls or design changes may be considered, or the situation may be escalated for management decision and formal risk acceptance.

    What residual risk includes and excludes

    Residual risk includes:

    • Risks that cannot be eliminated without fundamentally changing the process, technology, or product
    • Risks that remain due to practical limits on cost, technology, or feasibility of controls
    • Risks introduced by controls themselves (for example, complexity or new failure modes)

    Residual risk does not mean:

    • That no further risk exists after controls are in place
    • That the situation is inherently “safe” or “compliant”
    • That risks are formally accepted, unless this is explicitly documented through a risk acceptance process

    Use in workflows and systems

    Within industrial and regulated environments, residual risk is often:

    • Recorded and tracked in electronic quality management systems (eQMS), MES, or risk registers
    • Linked to specific controls such as standard operating procedures, digital work instructions, alarms, interlocks, or access controls
    • Re-evaluated after process changes, deviations, CAPA actions, or system upgrades
    • Used as input when prioritizing improvements, maintenance, or cybersecurity hardening

    Common confusion

    Residual risk vs. inherent risk: Inherent risk is the level of risk that exists before any controls are applied. Residual risk is the remaining risk after accounting for existing or planned controls.

    Residual risk vs. acceptable risk: Residual risk is a measured or estimated state. Acceptable risk is a threshold or decision. Residual risk may be judged acceptable or not, depending on defined criteria and documented justification.

    Residual risk vs. residual hazard: Residual hazard typically refers to the remaining hazardous condition (for example, a moving part that cannot be fully guarded), while residual risk considers both the hazard and the likelihood and severity of harm.

  • document control

    Document control is the managed process for creating, reviewing, approving, distributing, revising, and archiving documents in a controlled manner. In industrial and regulated manufacturing environments, it commonly refers to how procedures, work instructions, specifications, forms, records templates, and quality system documents are governed so that only current, approved versions are used.

    What document control includes

    In operations and quality systems, document control typically covers:

    • Document creation and identification: Defining document types, titles, unique IDs, authors, and owners.
    • Review and approval workflows: Routing drafts to designated reviewers and approvers before release.
    • Version management: Assigning version numbers or revisions, tracking changes, and maintaining revision history.
    • Controlled distribution: Ensuring the right people and systems have access to the current version (for example on the shop floor, in MES, or in training systems).
    • Access control: Defining who can view, edit, approve, or retire documents.
    • Change control linkage: Connecting document revisions to change requests, CAPAs, or engineering changes when relevant.
    • Retention and archiving: Retaining superseded and historical versions for traceability, audits, and investigations.
    • Obsolescence control: Clearly marking or removing obsolete documents so they are not used in operations.

    Document control is usually implemented through a Document Management System (DMS) or as part of a broader QMS, ERP, or MES platform. It often integrates with training management, electronic batch records, and equipment procedures so that operators and technicians only see approved, effective instructions.

    What document control does not include

    Document control focuses on governance of documents themselves, not on:

    • Managing real-time production data or sensor data.
    • Defining the technical content or engineering decisions inside a document.
    • Guaranteeing regulatory compliance on its own, although it supports compliance.

    Operational role in a QMS

    Within a Quality Management System, document control commonly applies to policies, standard operating procedures (SOPs), work instructions, forms, and templates that support quality planning, control, assurance, and improvement. Auditors often review document control processes to confirm that people are following current, approved instructions and that changes are traceable.

    Common confusion

    • Document control vs. record control: Document control governs living documents that can be revised (such as SOPs). Record control governs completed records that capture evidence of work performed (such as completed batch records or inspection results), which are not revised but may be corrected according to defined rules.
    • Document control vs. configuration management: Configuration management tracks the defined state of a product or system (parts, revisions, BOMs). Document control can be part of configuration management but does not by itself manage the full product configuration.

    Connection to MES/ERP and shop floor systems

    In integrated manufacturing environments, document control often links to MES and ERP so that:

    • Work instructions and procedures displayed at work centers are always the latest approved version.
    • Changes to specifications or routings trigger evaluation of affected documents.
    • Obsolete versions are automatically removed from use while still retained for traceability.

    Relation to the source context

    When QMS components are described as quality planning, quality control, quality assurance, and quality improvement, document control provides the underlying governance for the documents that define and support each of these activities. It does not replace these components but enables them to be executed consistently and to be demonstrated during audits.

  • configuration management

    Core meaning

    Configuration management is a controlled set of processes and records used to define, document, track, and change the configuration of a product, system, or software over its lifecycle. In an industrial context, it ensures that the as-designed, as-planned, as-built, and as-maintained configurations are known, consistent, and traceable.

    A “configuration” typically includes the approved structure and attributes of:

    – Product or system components (parts, assemblies, software versions)
    – Relationships between those components (bills of material, options, variants)
    – Applicable documentation (drawings, specifications, routings)
    – Approved changes (engineering changes, deviations, waivers)

    Use in industrial and regulated environments

    In manufacturing and other regulated operations, configuration management commonly refers to:

    – Defining the baseline configuration of a product or system (e.g., a specific aircraft tail number, medical device, or production line)
    – Managing engineering changes and ensuring they are reflected in manufacturing instructions, tooling, test plans, and quality records
    – Controlling which part numbers, revisions, and software versions are allowed in a given product configuration
    – Maintaining traceable links between requirements, design data, manufacturing data, and as-built records
    – Reconciling as-designed and as-built configurations for audit, maintenance, and safety investigations

    Configuration management can apply to both physical items (machines, products, tooling) and digital items (PLC programs, MES configurations, recipes, test scripts, CAD models).

    Boundaries and what it is not

    Configuration management:

    – Is a governance and record-keeping discipline, not just a software tool
    – Focuses on the identity, structure, and permitted variants of items, not on day-to-day production scheduling or inventory control
    – Overlaps with, but is distinct from:
    – **Change control / engineering change management**: the workflow for approving changes; configuration management ensures those approved changes are consistently reflected in configurations and records.
    – **Document control**: manages documents and revisions; configuration management relates documents to specific product or system configurations.
    – **Asset management**: tracks ownership, cost, and maintenance of equipment; configuration management focuses on the technical make-up and allowable states of that equipment or product.

    Common confusion and dual usage

    The term has two widely used meanings:

    1. **Product and system configuration management (PLM/ALM/CM)**
    – Dominant in engineering, manufacturing, aerospace, defense, and other regulated industries.
    – Manages configurations of physical products, embedded software, and associated documentation across design, production, and service.

    2. **Software and IT configuration management (DevOps/ITSM/OT)**
    – Dominant in IT, DevOps, and operations technology.
    – Manages configurations of servers, network devices, PLCs, applications, and environments (e.g., using tools like Ansible, Puppet, or version control systems).

    On this site, both meanings are relevant, but usage typically emphasizes product and system configuration management and its interaction with OT/IT systems such as MES, ERP, PLM, and control systems.

    Site context: link to inventory and aerospace

    In aerospace and other tightly regulated sectors, configuration management is closely tied to inventory accuracy and traceability:

    – Parts may be interchangeable only under strict configuration rules (by serial number, revision, or service bulletin status).
    – Each assembled asset (e.g., aircraft, engine, or critical system) has a controlled configuration definition, and every installed part must match that definition.
    – Frequent engineering changes require updates to BOMs, routings, and allowed substitutes; poor configuration management can cause inventory records to diverge from the physical build.
    – Serialized and life-limited parts need configuration records that show where they are installed, their usage, and which configuration rules apply.

    In this context, configuration management provides the reference structure that inventory, MES, and quality systems must follow to remain accurate and compliant.

    Interaction with digital systems

    Configuration management information is commonly implemented and maintained across multiple systems:

    – **PLM or PDM systems**: manage engineering configurations, part structures, and revisions.
    – **ERP and MRP systems**: manage manufacturing BOMs, approved substitutes, and effectivity dates tied to configurations.
    – **MES and shop-floor systems**: enforce which materials, tools, and software versions can be used for a given order or serial number.
    – **OT and control systems**: store and track configurations of PLC programs, recipes, and machine parameters as part of broader configuration management.

    These systems exchange configuration data so that the planned, produced, and maintained configurations stay aligned and traceable over time.

  • electronic signatures

    Core meaning

    Electronic signatures commonly refer to computer-based methods of capturing a person’s intent to sign, approve, or take responsibility for an action or record. They are used in place of handwritten (wet ink) signatures on electronic records.

    In industrial and regulated manufacturing environments, an electronic signature typically:

    – Uniquely identifies the signer (for example, via user ID)
    – Is linked to an authentication step (such as password, token, or other credential)
    – Is bound to a specific record, version, or transaction
    – Captures signing context (such as reason, role, and timestamp)

    Electronic signatures are usually implemented and controlled by IT/OT systems such as MES, LIMS, QMS, DMS, or ERP.

    Use in manufacturing and regulated operations

    In manufacturing systems, electronic signatures are commonly used to:

    – Approve or release production batches or lots
    – Sign off on electronic batch records (EBR) or device history records
    – Authorize deviations, nonconformances, and CAPA records
    – Approve work instructions, SOPs, and master data changes
    – Verify completion of critical process steps or inspections

    Systems such as MES often enforce signature prompts at defined workflow steps, ensuring that approvals are captured consistently across lines, shifts, and sites.

    Boundaries and characteristics

    Electronic signatures in this context:

    – **Include:**
    – Typed name with authenticated login and recorded intent
    – Clicked approval buttons linked to a verified user account
    – Digital certificates and cryptographic signatures when used to sign records
    – **Exclude:**
    – Unauthenticated name fields or free-text comments with no binding to a user account
    – General user login events that are not explicitly linked to a signature action

    Electronic signatures are usually part of a broader electronic records and audit trail framework, where records, signatures, and system events are stored together and protected from unauthorized change.

    Common confusion and related terms

    – **Electronic signature vs digital signature:**
    – *Electronic signature* is a broad term covering any electronic method to capture signing intent.
    – *Digital signature* usually refers to a specific cryptographic mechanism (public key infrastructure) that mathematically ensures integrity and authenticity. A digital signature is one technical way to implement an electronic signature.
    – **Electronic signature vs electronic record:**
    – The electronic record is the data being signed (for example, a batch record).
    – The electronic signature is the explicit action and data that indicate approval of that record.

    Application in MES and multi-site standardization (site context)

    When MES is used across multiple plants, electronic signatures are often configured as standard workflow controls:

    – Common signature points are defined in master workflows (for example, step completion, batch release, deviation approval).
    – Role-based rules determine who can sign which steps and with what reason codes.
    – Signature formats (such as number of credentials, required comments, or reasons) are harmonized to support governance, change control, and auditability.

    This standardization helps ensure that approvals and accountabilities are captured consistently, even when production occurs across different sites and legacy environments.

  • Change Impact Assessment

    Change Impact Assessment commonly refers to a structured evaluation of the potential effects of a proposed change before the change is approved or implemented. In regulated manufacturing and industrial operations, it is used to identify what the change could affect, how significant those effects may be, and what follow-up actions may be needed.

    The term usually applies to changes involving processes, equipment, software, documents, materials, specifications, workflows, data flows, or organizational responsibilities. It includes considering impacts on product quality, process performance, validated or controlled systems, training, documentation, traceability, and downstream operations. It is not the same as making the change itself, and it is not limited to technical risk alone.

    What it typically covers

    • The scope of the proposed change and what is being modified

    • Which products, lines, assets, records, or sites may be affected

    • Potential effects on quality, safety-related controls, compliance obligations, and customer requirements

    • Effects on connected systems such as MES, ERP, PLM, historians, SCADA, or quality systems

    • Whether procedures, work instructions, specifications, or training records need updates

    • Whether testing, verification, requalification, or revalidation may be required

    • Whether implementation should include approvals, staged rollout, or post-change review

    Operational meaning

    In practice, a Change Impact Assessment is often part of formal change control. A team documents the proposed change, identifies affected functions and records, rates impact or risk, and records required actions before execution. For example, changing a machine parameter recipe, revising an electronic batch record workflow, or updating an MES to ERP interface may each require an assessment of operational, quality, and data integrity impacts.

    Common confusion

    Change Impact Assessment is often confused with risk assessment, change control, and validation.

    • Risk assessment focuses on the likelihood and severity of harm or failure. A Change Impact Assessment may include risk considerations, but it is broader and asks what areas are affected.

    • Change control is the overall process for requesting, reviewing, approving, implementing, and closing a change. The assessment is one component of that process.

    • Validation or qualification assessment focuses specifically on whether a system, process, or equipment must be tested or requalified. That can be an outcome of the impact assessment, not the full definition of it.

    Why the term matters in manufacturing systems

    In integrated manufacturing environments, one change can affect multiple records and systems at once. A seemingly local update, such as changing part master data, a workflow step, or a work instruction, may also affect planning logic, device interfaces, genealogy records, reporting, or training requirements. Change Impact Assessment provides a documented way to identify those dependencies before implementation.

  • Stage-gate

    Stage-gate commonly refers to a structured process for managing work through a series of defined stages, with a formal review or decision point, called a gate, between stages. At each gate, stakeholders assess whether the work is ready to proceed, needs rework, should be paused, or should be stopped.

    In manufacturing and regulated operations, stage-gate is often used for product development, process changes, capital projects, validation-related activities, and implementation programs. The term describes the governance method around progression and approval, not the detailed execution of each task inside a stage.

    What it includes

    • Predefined stages such as concept, feasibility, development, testing, launch, or deployment

    • Entry and exit criteria for each stage

    • Gate reviews based on evidence, status, risk, cost, quality, and readiness

    • Named decision-makers or review groups responsible for approving progression

    • Documentation, records, and traceable decisions where required by internal controls or regulated workflows

    What it does not mean

    Stage-gate does not by itself define a specific quality standard, validation protocol, or regulatory requirement. It also is not the same as a production routing, shop floor operation sequence, or workflow engine, although software systems may support stage-gate reviews with approvals, status controls, and evidence collection.

    Operational meaning

    In practice, a stage-gate model appears as a controlled progression of work items or projects. For example, an engineering change may move through proposal, impact assessment, approval, implementation, and verification, with a gate at each transition. In digital systems, gates may be represented by workflow states, approval tasks, required attachments, e-signatures, or role-based release controls.

    Common confusion

    Stage-gate is often confused with a milestone plan. A milestone is a notable event or target date, while a gate is a decision point tied to explicit review criteria. It is also sometimes confused with phase-gate. In many organizations, phase-gate and stage-gate are used interchangeably, though local terminology may differ.

    Another common confusion is with manufacturing process stages. A stage-gate framework governs whether work can advance; it does not necessarily describe physical production steps such as machining, assembly, inspection, or packaging.

  • first article build

    A first article build commonly refers to the initial production build of a part, assembly, or product configuration used to confirm that the released design, planned manufacturing process, tooling, materials, and work instructions can produce the intended result. It is typically associated with the transition from design or setup into controlled production.

    The term describes the build activity itself, not only the inspection records generated from it. In regulated and quality-driven manufacturing, the first article build often provides the physical basis for downstream review activities such as dimensional verification, configuration checks, process confirmation, and formal first article inspection documentation where required.

    What it includes

    • The first planned build from approved drawings, specifications, and routing
    • Use of intended materials, tools, fixtures, equipment, and manufacturing methods
    • Verification that the product can be built consistently to the defined requirements
    • Collection of production and quality evidence that may support inspection, traceability, or process validation activities

    What it does not mean

    A first article build is not the same as an engineering prototype, lab sample, or informal trial unless those items are explicitly controlled as the initial production-representative build. It is also not identical to first article inspection. The build creates the item, while first article inspection is the review and verification activity performed on that item and its associated records.

    Operational meaning

    In manufacturing systems, a first article build may appear as a flagged work order, traveler step, routing status, or quality hold point. It is often linked to document control, revision status, material lot traceability, inspection results, and approval workflows so the organization can distinguish the initial production-representative unit from routine production.

    For example, when a new aerospace component is released, the first article build may be the first serialized unit produced under the intended process, with operators, inspectors, and planners capturing evidence needed for quality review and production release decisions.

    Common confusion

    First article build vs. first article inspection: the build is the act of making the item; the inspection is the act of verifying that item against defined requirements.

    First article build vs. prototype build: a prototype is often used for design learning or testing and may not follow the final production process. A first article build is usually expected to be production-representative.

    First article build vs. pilot run: a pilot run may involve multiple units to test readiness or flow. A first article build usually refers to the initial unit or initial build event used for that confirmation.

  • configuration baseline

    Core meaning

    A **configuration baseline** commonly refers to a formally identified and approved snapshot of a system’s configuration items at a specific point in time. It is used as a stable reference against which future changes are proposed, evaluated, implemented, and verified.

    In industrial and manufacturing environments, this typically includes software settings, parameter sets, master data, documentation, and sometimes hardware versions that together define how a system is intended to operate at that point.

    What a configuration baseline includes

    A configuration baseline usually consists of:

    – **Defined scope of items**: The configuration items (CIs) under control, such as MES recipes, routing rules, ERP–MES integration mappings, control system parameters, or quality limits.
    – **Versioned artifacts**: Exact versions of files, data sets, and settings (for example, MES configuration packages, PLC logic versions, or interface specifications).
    – **Associated documentation**: Approved specifications, design documents, operating instructions, and test/validation evidence that describe and support the baseline.
    – **Unique identification**: A baseline ID, effective date, and ownership, so teams can clearly reference and retrieve it.

    The baseline is not every possible detail in a system, but the defined set of items that must stay controlled and traceable for operational, quality, or regulatory reasons.

    How configuration baselines are used

    In real workflows, configuration baselines are used to:

    – **Provide a reference state**: Teams know exactly which configuration is currently considered the “approved” or “in-production” state.
    – **Support change control**: Proposed changes are compared to the baseline to understand impact, document differences, and decide whether to approve the change.
    – **Enable rollback and recovery**: If a change causes issues, the prior baseline can be restored, either fully or selectively.
    – **Support audits and investigations**: Baselines show what configuration was in effect at a given time when a deviation, complaint, or incident occurred.

    In regulated manufacturing, baselines are often linked to formal change control, testing, and validation records in quality or configuration management systems.

    Site context: MES and process improvement

    Applied to **MES and related OT/IT systems**, a configuration baseline commonly refers to an approved snapshot of:

    – MES functional configurations (workflows, routing, master data, user roles)
    – Integration mappings with ERP, LIMS, historians, or automation systems
    – Parameter sets and rules that implement current process methods and quality standards

    In continuous improvement and brownfield environments, baselines help prevent **configuration drift** between documented process improvements and what is actually configured in the MES and shop-floor systems. Change requests, backlog items, and CI initiatives are managed relative to the current baseline so that improvements are fully implemented, tested, and traceable.

    Boundaries and exclusions

    A configuration baseline **is**:

    – A controlled reference state for defined configuration items
    – An anchor for formal change control and traceability
    – A point-in-time snapshot that can be compared against later states

    A configuration baseline **is not**:

    – A project plan or roadmap for future changes
    – A generic backup without clear scope or approval status
    – A real-time representation of the current system state (it only reflects the state at the time it was defined and approved)

    Common confusion and related terms

    – **Backup vs. configuration baseline**: A backup is a technical copy of data or systems for recovery. A configuration baseline is a **managed, approved reference**, often supported by backups but governed through configuration and change management processes.
    – **Golden image vs. configuration baseline**: A golden image is usually a standard system image used for deployment. A configuration baseline is broader and may cover multiple systems, settings, and documents, not just a single deployable image.
    – **Current configuration vs. baseline**: The current live configuration may have diverged from the last baseline if changes have been made but not yet formally baseline’d or fully approved.