Connect981 – Content Dev

Glossary Tag: process monitoring

  • Fielded Fleet

    Fielded Fleet commonly refers to the set of physical assets that have been delivered to users, deployed into operational service, and are no longer only in production, storage, or test status. In aerospace, defense, industrial equipment, and similar regulated environments, this usually means the installed base of aircraft, vehicles, systems, machines, or serialized units that are actively in use by operators or customers.

    The term includes equipment that has entered service and is being maintained, repaired, upgraded, inspected, or monitored over time. It does not usually include units that are still being manufactured, units held only as unfinished inventory, or prototypes that have not been formally deployed for operational use.

    How the term is used operationally

    In operations and digital systems, a fielded fleet is often the population tracked for service history, configuration status, maintenance events, parts consumption, reliability trends, and retrofit campaigns. Data about the fielded fleet may reside across ERP, MES, PLM, EAM, MRO, or service management systems, depending on how the organization manages as-built and as-maintained records.

    • For manufacturers, it can mean all delivered units under support.

    • For operators, it can mean all in-service assets under their control.

    • For sustainment teams, it often means the installed base that requires ongoing traceability and maintenance lineage.

    What it includes and excludes

    Fielded fleet usually includes serialized assets that are operationally deployed, whether they are currently active, temporarily down for maintenance, or rotating through scheduled service.

    It may exclude:

    • work in process or finished goods not yet delivered

    • development prototypes not accepted for operational use

    • standalone spare parts unless they are installed in a fielded unit

    • test rigs or lab systems that are not part of the deployed asset population

    Common confusion

    Fielded fleet is often confused with installed base. In many organizations the terms are close, but installed base can be broader and may include all deployed equipment known to exist, even if some units are inactive or outside a current support scope.

    It is also different from production fleet or manufactured units, which may count everything built rather than everything actually deployed into service.

    In defense and aerospace contexts, the term is also distinct from a single platform or program. A fielded fleet refers to the population of deployed units, not the design family by itself.

    Why it matters in regulated operations

    Organizations commonly use the fielded fleet as the reference population for service bulletins, retrofit planning, warranty analysis, reliability monitoring, and traceability of changes over time. In regulated environments, the accuracy of fielded fleet records affects how teams understand which units are in service, what configuration each unit carries, and what maintenance or quality actions may apply to them.

  • single-source supplier

    Core meaning

    A **single-source supplier** is a supplier that is, in practice, the only viable or approved provider for a specific part, material, or service within an organization’s supply base. The customer may be able to buy similar items elsewhere in theory, but due to design, qualification, contractual, or operational constraints, all purchases of that item are routed to this one supplier.

    In industrial and regulated manufacturing environments, single-source suppliers are common for:

    – Custom-designed or proprietary components
    – Safety- or quality-critical items with formal qualification or validation
    – Specialized processes (e.g., certain coatings, heat treatments, or software modifications)
    – Tooling, fixtures, or equipment for which the OEM is the only approved vendor

    Use in operations and supply chain

    In real workflows, a single-source supplier typically means:

    – The item has one approved vendor in the ERP/MRP or vendor master for that part number.
    – Alternate suppliers exist only with significant requalification, redesign, or regulatory impact.
    – Lead time, capacity, and disruption at that supplier directly affect production, maintenance, or service levels.

    Organizations often:

    – Flag single-sourced parts in their planning or risk registers.
    – Apply additional monitoring, contractual controls, or inventory strategies around these items.
    – Coordinate closely with quality, engineering, and procurement before attempting to add or change a source.

    Boundaries and exclusions

    A single-source supplier **is not** the same as:

    – **Sole-source supplier**: Often used to mean there is literally no other supplier in the market (e.g., unique IP or monopoly). “Single-source” usually reflects the customer’s current sourcing choice and approvals, not global market reality.
    – **Preferred supplier**: A vendor that gets the majority of spend but can be substituted easily. Single-source status implies substitution is non-trivial.

    Single-source status is defined **from the buying organization’s perspective**, not the entire industry. Another manufacturer might have different approved sources for the same generic item.

    Risk and reliability considerations

    Because all supply for the affected item flows through one organization, single-source suppliers are commonly treated as higher risk in:

    – Business continuity and resilience assessments
    – Capacity and lead-time planning
    – Supplier risk and quality management reviews

    Common risk factors include:

    – Long or variable lead times
    – Fragile financial, geopolitical, or logistics context
    – Tight capacity relative to demand
    – Complex or lengthy qualification/approval cycles that delay switching

    Site context: maintenance and AOG-type scenarios

    In maintenance-intensive sectors (e.g., aviation, pharmaceuticals, continuous process plants), single-source suppliers are closely watched for items whose absence can halt operations, such as:

    – Safety-critical units or assemblies with unique approvals
    – Long-lead structural or custom parts
    – Components with unique repair capabilities or IP

    For these items, planners and reliability teams typically map single-source status when assessing downtime or “grounding” risk, and may adjust stocking policies, contingency plans, or engineering change priorities accordingly.

    Common confusion and misuse

    – **Market vs. internal single sourcing**: A part may be technically multi-source in the market, but if only one vendor is qualified and set up in the ERP, it functions as single-source for that plant or company.
    – **Temporary vs. structural**: A part may be temporarily single-source (e.g., during ramp-up of a second source). Some organizations track planned vs. structural single-source states separately.

    Careful use of terminology in specifications, contracts, and risk registers helps distinguish policy choices (choosing to buy from one source) from hard constraints (only one feasible or approved source exists).

  • product traceability

    Product traceability commonly refers to the ability to identify and follow a product, its components, and associated data through all stages of production, processing, distribution, and sometimes use and service. In industrial and regulated manufacturing environments, this includes linking materials, process steps, equipment, operators, test results, and quality decisions to specific product units or batches.

    What product traceability includes

    In practice, product traceability typically covers:

    • Identification: Unique identifiers such as serial numbers, lot numbers, batch IDs, or barcodes applied to materials, components, and finished goods.
    • Process history: Records of when, where, and how a product was manufactured, including work orders, process parameters, and equipment used.
    • Material genealogy: The relationships between raw materials, components, subassemblies, and final products.
    • Quality and test data: Inspection results, measurements, nonconformances, rework, and release decisions linked to specific units or lots.
    • Supply chain data: Supplier information, incoming inspection results, and shipment/receiving records.
    • Distribution records: Where each product unit or lot was shipped, installed, or used, often including customer or site information.

    Product traceability can be implemented at different levels of granularity, from batch-level (lot traceability) to unit-level (full serial traceability). In high-risk or highly regulated sectors, unit-level traceability is often required or expected.

    Operational meaning in manufacturing systems

    Operationally, product traceability relies on coordinated data capture across OT and IT systems. Typical enablers include:

    • MES and shop floor systems capturing work-in-process, routing, operator actions, and process data.
    • ERP and inventory systems recording material movements, batch/lot assignments, and shipments.
    • Quality systems (QMS, LIMS, SPC) storing inspection, test, and deviation data linked to product identifiers.
    • Labeling and identification technologies such as barcodes, QR codes, RFID, or nameplates.

    These systems together support end-to-end tracking, from raw material receipt through final shipment and, where relevant, field service or recall actions.

    Role in standards and regulated environments

    In regulated or safety-critical industries, product traceability is often a key expectation within quality management and compliance frameworks. It supports:

    • Defect and complaint investigation by enabling rapid identification of affected lots or serial numbers.
    • Targeted containment and recalls by tracing forward from suspect components to finished goods and customers.
    • Root cause analysis by providing linked histories of materials, processes, and test results.
    • Supplier and internal audit evidence by demonstrating how product records are connected and retrievable.

    Automotive quality standards, such as IATF 16949, commonly refer to product traceability expectations, especially where safety, regulatory, or customer-specific requirements apply.

    What product traceability is not

    Product traceability is related to, but distinct from, several nearby concepts:

    • It is not only a labeling activity. Labels provide identifiers, but traceability requires consistent capture and maintenance of linked records.
    • It is not the same as production scheduling. Scheduling defines when and where work should happen; traceability describes what actually happened and to which product units.
    • It is not limited to inbound and outbound tracking. Effective traceability spans intermediate process steps and in-process transformations.

    Common confusion

    Product traceability is closely related to:

    • Genealogy: Often used to describe the parent-child relationships of materials and components that make up a product. Genealogy is a core part of traceability.
    • Lot traceability: Traceability at batch or lot level instead of individual serial number. This is a subset of product traceability with coarser granularity.
    • Process traceability: Focused on tracking process conditions and steps. Product traceability typically combines both product and process perspectives.

    Link to the automotive quality context

    In automotive and similar long-lifecycle industries, product traceability is often addressed within quality management systems aligned with standards such as IATF 16949. Requirements typically include the ability to identify products and components, trace them back to manufacturing records and suppliers, and trace them forward to vehicles or assemblies in the field, especially where safety or regulatory characteristics are involved.

  • IT

    IT, short for Information Technology, commonly refers to the systems, infrastructure, software, and services used to create, process, store, secure, and transmit digital information within an organization. In industrial and manufacturing environments, IT typically covers business and enterprise systems, data centers, corporate networks, and cloud services, as distinct from plant-floor operational technology (OT).

    Scope in industrial and regulated environments

    In manufacturing organizations, IT usually includes:

    • Enterprise applications such as ERP, PLM, LIMS, QMS, CRM, and HR systems
    • Office productivity and collaboration tools, email, and document repositories
    • Corporate and site-wide networks (LAN, WAN, VPN, Wi-Fi) and internet connectivity
    • Servers, storage, virtualized environments, and cloud platforms
    • Directory services, identity and access management, and user account provisioning
    • Enterprise cybersecurity controls such as firewalls, endpoint protection, and monitoring tools

    IT departments in regulated industries often work closely with quality, compliance, and operations teams to support validated systems, data integrity practices, and secure interfaces between IT systems and OT systems such as SCADA, DCS, and MES.

    Role in security and compliance

    Within information security frameworks such as ISO 27001, IT commonly represents a major portion of the information assets and infrastructure in scope. This can include:

    • Networks and communication links that connect manufacturing sites and corporate locations
    • Systems that store or process regulated records, technical data, or confidential information
    • Supporting services like backup, recovery, logging, and centralized administration

    IT responsibilities in this context typically cover implementing and operating security controls, managing changes to systems and networks, and coordinating with OT teams where there are shared or boundary systems.

    Common confusion

    IT vs OT: IT focuses on business and enterprise information systems, while OT (Operational Technology) refers to the hardware and software that monitor or control physical equipment and processes on the shop floor. In modern plants, IT and OT often converge in areas such as MES, data historians, and edge gateways, which require clear ownership and security boundaries.

    IT vs IS: IT refers to the technology and systems themselves, while information security (IS) or cybersecurity refers to the protection of those systems and the information they handle. IT teams frequently operate or host security controls but are not identical to the security function.

    Relation to ISO 27001 scope

    When defining the scope of an ISO 27001 Information Security Management System (ISMS) in a manufacturing company, IT elements usually form a substantial part of what is included. The scope statement often clarifies which IT networks, applications, data centers, and cloud services are covered, and how shared IT/OT components are treated, especially in brownfield environments with legacy systems and constrained change windows.

  • Nonconformance Code

    A nonconformance code is a standardized identifier used to classify a nonconformance in a quality or manufacturing system. It commonly appears as a short alphanumeric value, picklist option, or controlled label in records such as NCRs, inspection results, supplier issues, scrap reports, or CAPA-related workflows.

    The code does not describe the entire event by itself. It is a structured way to categorize the issue so that people and systems can sort, trend, route, report, and analyze nonconformances consistently across products, work centers, suppliers, or sites.

    What it typically includes

    • The type of nonconformance, such as dimensional, documentation, material, process, or labeling issue

    • Sometimes the source or point of detection, such as incoming inspection, in-process inspection, final inspection, or customer return

    • Sometimes disposition or workflow classification, depending on how the quality system is configured

    In digital quality systems, a nonconformance code may drive reporting logic, approvals, escalation paths, or links to downstream activities such as MRB review, rework, scrap tracking, supplier follow-up, or corrective action.

    What it is not

    A nonconformance code is not the same as the full nonconformance record. The full record usually includes details such as part or batch affected, requirement not met, quantity, evidence, containment, disposition, and approvals. The code is only one controlled data element within that record.

    It is also not necessarily a root cause code. Some organizations use separate coding structures for defect type, cause, containment, and disposition to avoid mixing problem description with cause analysis.

    Common confusion

    Nonconformance code is often confused with defect code, rejection code, disposition code, or root cause code. These may overlap in some systems, but they are not always interchangeable:

    • A defect or rejection code usually identifies what was found wrong

    • A disposition code usually identifies what will be done with the affected item, such as rework or scrap

    • A root cause code usually identifies why the issue happened after investigation

    Organizations sometimes use one code set for several of these purposes, but the distinction matters for reporting accuracy and trend analysis.

    Manufacturing context

    In manufacturing and regulated environments, nonconformance codes support more consistent data capture across MES, QMS, ERP, and supplier quality workflows. For example, a receiving inspector might select a code for a material certification mismatch, while an in-process operator or quality technician might select a code for an out-of-tolerance feature. When codes are standardized, quality teams can compare patterns across jobs, lines, products, and suppliers more reliably.

  • Process Parameter

    A process parameter is a measurable or controllable condition that defines how a manufacturing or industrial process is run. It commonly refers to variables such as temperature, pressure, speed, feed rate, torque, time, humidity, flow rate, or setpoint values.

    Process parameters are used in work instructions, recipes, routings, control plans, MES records, SCADA systems, quality records, and equipment settings. They help describe the conditions under which an operation was performed and may be recorded for traceability, troubleshooting, process monitoring, or product quality review.

    A process parameter should not be confused with a product characteristic. A process parameter describes the process input or operating condition, while a product characteristic describes the resulting part, material, or assembly feature. For example, oven temperature is a process parameter; coating thickness after curing is a product characteristic.

    Some parameters may be identified as critical process parameters when variation in the parameter can materially affect quality, yield, safety, or process capability. The broader term process parameter does not imply that the parameter is critical unless that status is defined by the applicable process, control plan, or quality system.

  • bottleneck analysis

    Bottleneck analysis is the systematic identification and evaluation of the process step, resource, equipment, material flow, or decision point that limits overall throughput. In manufacturing, it is used to understand where work is waiting, capacity is constrained, or production flow is being slowed.

    The analysis commonly uses data such as cycle time, queue time, work-in-process, downtime, changeover time, labor availability, yield loss, and schedule adherence. It may be performed with shop-floor observations, value stream mapping, MES data, ERP schedule data, or operational performance metrics such as OEE and non-production time.

    A bottleneck is not always a permanently fixed asset or workstation. It can shift by product mix, staffing, material availability, inspection load, engineering holds, or maintenance conditions. Bottleneck analysis should also not be confused with root cause analysis, although the two are often connected. Bottleneck analysis identifies where flow is constrained; root cause analysis examines why that constraint exists.

    In industrial systems, bottleneck analysis is commonly applied in capacity planning, scheduling, line balancing, continuous improvement, and performance monitoring. For example, an inspection station with long queues may be the current bottleneck even if upstream machining equipment has lower nominal capacity.

  • Purchase Order

    A Purchase Order (PO) is a formal commercial document issued by a buying organization to a supplier that authorizes the purchase of specified goods or services under defined terms and conditions. It is a key control instrument in procurement and financial processes, especially in industrial and regulated manufacturing environments.

    Core characteristics

    A Purchase Order typically includes:

    • Unique PO number for identification and traceability
    • Buyer and supplier information
    • Description of goods or services, including part numbers or SKUs
    • Quantities, prices, currency, and payment terms
    • Required delivery dates and delivery locations
    • Applicable quality, regulatory, or technical requirements
    • Reference to related contracts, quotes, or framework agreements

    In most organizations, Purchase Orders are created, approved, and maintained in an ERP, procurement, or financial system. They provide the commercial basis for receiving, inspection, and invoicing activities.

    Role in industrial and regulated environments

    In manufacturing and other industrial operations, a Purchase Order commonly serves to:

    • Control external spending by requiring authorization before purchase
    • Link incoming materials or services to cost centers, projects, or products
    • Support material traceability by associating received lots or serials with a PO number
    • Reference required specifications, certificates, or regulatory constraints for supplied items
    • Provide a contractual baseline for supplier performance and dispute handling

    On the shop floor, PO numbers are often used to identify which incoming materials, components, or outsourced services belong to a particular order, batch, or customer project. Inspection records, nonconformance reports, and supplier corrective actions may all reference the relevant PO.

    Interaction with other operational documents

    Purchase Orders are related to, but distinct from, several other common documents:

    • Work Orders (WO): A WO instructs internal or external resources to perform work (such as manufacturing, maintenance, or rework). A WO may depend on materials or services procured via one or more POs, but the WO governs execution, while the PO governs purchasing.
    • Production Orders / Manufacturing Orders: These define what to make, in what quantity, and by when. They may consume materials that were acquired under one or more POs.
    • Purchase Requisitions: Internal requests that precede approval and conversion into a formal PO.
    • Invoices: Supplier billing documents that typically reference a PO number for matching and approval.

    Common confusion

    Purchase Orders are commonly confused with:

    • Work Orders: A PO is a commercial agreement with a supplier. A WO is an instruction to perform work, often within MES, CMMS, or maintenance systems. They may reference each other but serve different control and traceability purposes.
    • Contracts: A PO may operate under an existing contract or framework agreement. The contract sets the broader legal relationship, while the PO specifies a particular transaction under that relationship.

    Context from the PO vs WO distinction

    In discussions that compare PO and WO, the Purchase Order represents the financial and commercial commitment recorded in ERP or procurement systems, while the Work Order represents operational work instructions in systems such as MES or CMMS. Understanding this separation helps maintain clear boundaries between purchasing control, production or maintenance execution, and compliance documentation.