Connect981 – Content Dev

Glossary Tag: process monitoring

  • Supplier Approval

    Supplier approval commonly refers to the documented process used to evaluate, qualify, and authorize a supplier to provide specific materials, components, services, or outsourced operations. In regulated and quality-sensitive manufacturing, it usually includes checks on the supplier’s capability, quality controls, documentation, and any requirements tied to the product, process, or customer.

    It is not simply adding a company to a vendor list for purchasing convenience. Supplier approval is narrower and more controlled: a supplier may be approved only for certain part families, processes, sites, or service types, and that approval may be conditional, time-limited, or subject to ongoing review.

    What it typically includes

    • initial evaluation of the supplier’s capabilities and scope

    • review of quality records, certifications, questionnaires, or audit results where applicable

    • assessment of process controls, traceability, and documentation practices

    • formal decision to approve, conditionally approve, or reject the supplier for a defined scope

    • maintenance of an approved supplier list or equivalent master record

    • periodic re-evaluation based on performance, changes, or risk

    How it appears in operations and systems

    Operationally, supplier approval often connects purchasing, quality, engineering, and supplier management workflows. It may appear in ERP, QMS, SRM, or supplier portal processes as approval status, approved supplier lists, qualification records, required documents, performance history, and reapproval triggers. For example, a buyer may be blocked from issuing a purchase order for a special process unless the supplier is approved for that exact service.

    Common confusion

    Supplier approval is often confused with supplier onboarding, vendor setup, and supplier qualification.

    • Supplier onboarding usually covers administrative setup such as tax, payment, and contact data.

    • Vendor setup often means creating the supplier record in an ERP or procurement system.

    • Supplier qualification is sometimes used interchangeably, but in many organizations it refers more specifically to the assessment phase before formal approval.

    • Supplier certification generally implies a separate formal designation or external status and should not be assumed from approval alone.

    Manufacturing context

    In manufacturing, supplier approval is especially relevant for raw materials, critical components, calibration providers, contract manufacturers, and outside processing such as plating, heat treatment, or nondestructive testing. The level of review commonly varies with risk, product criticality, regulatory expectations, and customer requirements.

  • Maturity assessment

    A maturity assessment is a structured evaluation of how developed, repeatable, controlled, and measurable a process, system, function, or organizational capability is. In manufacturing and regulated operations, it commonly refers to reviewing current practices against a defined set of maturity levels, criteria, or capabilities rather than checking whether a single requirement is simply met or not met.

    The term usually includes an appraisal of process definition, execution consistency, governance, data quality, roles, documentation, integration, and performance monitoring. It can be applied to areas such as quality management, MES usage, digital work instructions, cybersecurity, maintenance, supplier management, or ERP and shop floor integration.

    A maturity assessment is not the same as a certification, formal audit result, or pass/fail compliance determination. It is generally a diagnostic tool used to describe the current state and identify gaps between ad hoc practice and more standardized or optimized operation.

    How it is used in operations

    In practice, a maturity assessment often looks at whether work is informal or documented, whether execution varies by shift or site, whether records are complete and traceable, and whether systems are integrated or reliant on manual workarounds. Results are commonly summarized by capability area and maturity level, with examples of observed strengths, weaknesses, or dependencies.

    • Example: assessing whether nonconformance handling is paper-based, partially digital, or fully integrated with quality records and corrective action workflows.
    • Example: assessing whether production instructions are tribal knowledge, controlled documents, or role-based digital work instructions tied to execution data.

    Common confusion

    Maturity assessment vs. audit: An audit compares evidence against specific requirements or internal procedures. A maturity assessment compares current capability against a progression model or operating-state framework.

    Maturity assessment vs. gap assessment: A gap assessment focuses on what is missing relative to a target state or requirement set. A maturity assessment usually goes further by characterizing the degree of development across multiple levels.

    Maturity assessment vs. KPI review: KPI review looks at performance results. A maturity assessment looks at the underlying management system, practices, controls, and consistency that shape those results.

    What it typically includes and excludes

    It typically includes interviews, document review, workflow observation, scoring criteria, and comparison across functions, sites, or capability domains.

    It does not necessarily include detailed system validation, legal interpretation, or an official finding of compliance status unless those activities are separately defined.

  • layered process audit

    A layered process audit commonly refers to a structured, recurring check of whether defined process steps, standard work, and key controls are being followed on the shop floor or in operational support processes. The “layered” part means the audit is performed by different levels of the organization, such as team leads, supervisors, managers, and sometimes quality or plant leadership, using aligned audit questions at different frequencies.

    In manufacturing, the term usually applies to routine verification of process discipline rather than a one-time system audit. It focuses on whether critical operating conditions are present and sustained, for example whether the right work instruction is in use, required checks are completed, tools are set correctly, materials are identified properly, and escalation steps are followed when something is out of condition.

    What it includes

    • Brief, repeated audits tied to a process, line, cell, area, or support function

    • Standardized questions or check points based on process risks or known failure modes

    • Participation by multiple management layers with defined cadence

    • Documentation of findings, follow-up actions, and closure status

    • Use as an operational control to detect drift from standard work

    It does not usually mean a financial audit, a certification audit, or a full quality management system audit. It is narrower and more operational than those activities.

    How it appears in workflows and systems

    Layered process audits may be managed on paper, in spreadsheets, or in MES, QMS, mobile audit, or digital work instruction platforms. In digital environments, an LPA program often includes scheduled audit tasks, role-based assignments, evidence capture, timestamps, exception logging, and action tracking. Results may also be reviewed alongside nonconformance, CAPA, scrap, rework, or training records to identify recurring process weaknesses.

    Common confusion

    Layered process audit is often confused with product inspection. They are related but not the same. Product inspection checks whether the output meets requirements. A layered process audit checks whether the process conditions and behaviors intended to produce conforming output are actually being followed.

    It is also commonly confused with an internal quality audit. An internal audit typically reviews broader system conformance, procedures, or compliance against an audit scope. A layered process audit is usually shorter, more frequent, and focused on day-to-day execution at the point of use.

    Manufacturing example

    On an assembly line, an operator lead might verify each shift that the current work instruction revision is posted and torque checks are recorded. A supervisor might review the same area daily for material identification and reaction-plan compliance. A manager might audit weekly for sustained adherence and closure of prior findings. Together, those checks form the layered approach.

  • Cross-functional team

    A cross-functional team is a group of people from different business functions who work together on a shared objective, process, problem, or project. In manufacturing and regulated operations, this commonly includes participants from areas such as production, quality, engineering, maintenance, supply chain, IT, validation, regulatory, or finance.

    The term refers to the mix of functions represented on the team, not to any specific reporting structure. A cross-functional team may be temporary, such as for an investigation or system implementation, or ongoing, such as for operational governance, change control, or continuous improvement.

    What it includes

    A cross-functional team commonly brings together different perspectives needed to make, review, or support decisions that affect more than one part of the operation. Examples include:

    • investigating a nonconformance or deviation
    • reviewing process changes that affect production, quality, and documentation
    • planning MES and ERP integration across shop floor and business systems
    • coordinating new product introduction, transfer, or scale-up

    In practice, the team may share data, assess impacts across departments, align handoffs, and document decisions or actions.

    What it does not mean

    A cross-functional team is not the same as a department, committee, or project team unless it actually includes multiple functions. It also does not mean that every member has equal authority over all decisions. In many organizations, decision rights still follow role, procedure, or quality system requirements.

    Common confusion

    Cross-functional team vs. multidisciplinary team: These terms are often used interchangeably. In business and manufacturing settings, cross-functional usually emphasizes representation from different organizational functions.

    Cross-functional team vs. matrix organization: A matrix organization is a broader reporting or management structure. A cross-functional team is a working group within or across that structure.

    Cross-functional team vs. interdepartmental workflow: A workflow can pass through several departments without a standing team being formed. A cross-functional team implies active collaboration among members.

    Manufacturing context

    Cross-functional teams are common where work crosses system, compliance, and operational boundaries. For example, a change to routing, inspection steps, or electronic records may require input from manufacturing, quality, engineering, and IT to understand downstream effects and required documentation.

  • constraint management

    Constraint management is the structured process of identifying, monitoring, and addressing the factor that currently limits the performance of a manufacturing system. In industrial operations, the constraint is commonly the resource, step, policy, or supply condition that restricts throughput, schedule attainment, lead time, or capacity.

    The term is most often used in production planning, operations management, and continuous improvement. A constraint may be a bottleneck machine, limited skilled labor, inspection capacity, material availability, tooling, batch rules, or an information flow issue between systems such as ERP and MES. Managing the constraint means making that limiting factor visible, protecting its effective use, and aligning upstream and downstream activity around it.

    Constraint management is related to bottleneck analysis, but the terms are not identical. A bottleneck usually refers to a capacity-limiting step in a process, while a constraint can also be procedural, commercial, data-related, or organizational. In practice, the active constraint can shift over time as demand, product mix, staffing, or equipment status changes.

    In digital manufacturing environments, constraint management often relies on schedule data, WIP visibility, downtime signals, and material status from MES, ERP, planning, and quality systems. The goal is not simply to keep all resources busy, but to manage the limiting condition that governs overall system output.

  • bottleneck resource

    A bottleneck resource is the resource in a process that most limits overall throughput. It is the step, machine, work center, labor skill, or inspection point whose available capacity is lower than the demand placed on it, causing work to queue and constraining output for the larger system.

    In manufacturing, the term is used in production planning, scheduling, lean improvement, and capacity analysis. The bottleneck resource is not simply any busy asset. It is the constraining resource that governs how much product can move through the process over a given period. If upstream operations run faster, inventory or WIP typically builds in front of it rather than increasing finished output.

    A bottleneck resource can be permanent or temporary. For example, a specialized heat treat oven may be the recurring bottleneck in one plant, while a final inspection station may become a temporary bottleneck during a surge in demand or a staffing shortage. In MES, ERP, and planning contexts, identifying the bottleneck resource helps with realistic scheduling, queue management, and capacity planning.

    The term is commonly confused with a general constraint or with low utilization elsewhere in the line. A bottleneck resource is a specific capacity-limiting point in the workflow. Other resources may still affect lead time, quality, or cost without being the current bottleneck.

  • BOM

    Core meaning

    BOM (bill of materials) is a structured list that defines all items required to build, test, and package a product or configured item. It typically includes:

    – Components and subassemblies
    – Raw and semi-finished materials
    – Standard parts (e.g., fasteners, fittings)
    – Consumables when they are controlled (e.g., adhesives, sealants)
    – Documentation and references needed for release (e.g., drawings, specs)

    A BOM usually specifies quantities, units of measure, revision or version identifiers, and relationships between parent items and child components.

    Use in manufacturing and regulated operations

    In industrial and regulated environments, a BOM commonly refers to one or more of the following structures:

    – **Engineering BOM (EBOM)**: Product definition from design/engineering, aligned to drawings and design intent.
    – **Manufacturing BOM (MBOM)**: Product definition aligned to how the product is built, sequenced, or grouped on the shop floor.
    – **Service or maintenance BOM**: Parts and assemblies needed to maintain, repair, or overhaul the product.

    In practice, BOMs are used to:

    – Drive material planning and procurement in ERP/MRP
    – Define what must be issued to, and consumed on, work orders in MES
    – Support configuration control and variation management (options, variants, effectivity)
    – Provide traceability for components and materials in quality and compliance records

    BOM in MES, quality, and configuration control (site context)

    Within MES and quality systems, especially in high-regulation sectors such as aerospace:

    – The BOM identifies **which part numbers and revisions** are valid for a given product or work order.
    – MES may compare **actual components scanned or recorded on the line** against the BOM to detect:
    – Wrong part numbers
    – Wrong revisions or superseded parts
    – Missing required components
    – Alerts can be configured when a build deviates from the approved BOM, supporting scrap prevention and nonconformance control.
    – BOM information is often linked to **routing/operations**, **process plans**, and **specification documents** to ensure the right material and documentation are used together.

    Boundaries and exclusions

    – A BOM defines **what** items are required, not **how** they are processed. Operation steps, machines, and process parameters are typically defined in routings, travelers, or work instructions, not in the BOM itself.
    – A BOM is not the same as:
    – A **routing** or process plan (sequence of operations and resources)
    – A **recipe** (parameterized processing instructions, often for process industries)
    – A **production schedule** (timing and quantity of planned orders)

    However, all of these structures usually reference or depend on a consistent, controlled BOM.

    Common variations of BOM structures

    Organizations may define specialized BOM types, such as:

    – **Configurable or variant BOM**: Supports options and variants, often used with configuration rules.
    – **Phantom BOM**: Logical grouping of items used for planning, not built as a separate stockkeeping unit.
    – **As-planned, as-released, as-built, and as-maintained BOM views**: Different life-cycle views of the same product, important for traceability in regulated industries.

    Terminology and exact behavior can differ by ERP/MES vendor, but all of these remain specific ways of structuring the underlying bill of materials.

    Common confusion and misuse

    – **BOM vs. part list on a drawing**: A drawing parts list may be one representation of a BOM, but in most controlled environments the master BOM is maintained in a PLM, PDM, or ERP system, with drawings acting as a reference.
    – **BOM vs. inventory list**: A BOM specifies what is required for one unit (or another defined quantity) of a product. Inventory lists show what is available in stock, regardless of any single product.
    – **BOM vs. specification**: Specifications define requirements (e.g., material properties, tolerances). The BOM references which materials or parts are used to meet those requirements, but does not replace the specs themselves.

    Understanding these boundaries helps keep engineering change, MES configuration, and quality records aligned around a single, controlled definition of the product structure.