Connect981 – Content Dev

RSC Cluster: Procurement, RFQ and Buyer Enablement

The Procurement, RFQ and Buyer Enablement Cluster focuses on reducing friction in sourcing and supplier communication. It explains how incomplete RFQs, unmanaged changes, and email-driven workflows create downstream execution problems. The content defines a minimum viable RFQ data set tied to execution and quality requirements. This cluster helps buyers move faster without creating chaos.

  • RFQ

    RFQ commonly refers to a Request for Quote, a purchasing document or sourcing request used to ask one or more suppliers for pricing and related commercial details for defined goods or services. It is typically used when the buyer can describe the requirement clearly enough for suppliers to quote against a known scope, quantity, specification, or part list.

    In manufacturing and regulated operations, an RFQ often includes part numbers, drawings or revisions, quantities, delivery expectations, quality requirements, approved process needs, and commercial terms to be quoted. It may be managed in ERP, procurement, supplier portal, PLM-linked sourcing workflows, or email-based purchasing processes.

    What it includes and excludes

    An RFQ is mainly about obtaining a price and quote conditions for a defined requirement. It may also collect lead time, minimum order quantity, tooling cost, packaging details, and exceptions to requirements.

    It is not the same as a purchase order. An RFQ requests information from suppliers, while a purchase order is commonly used to authorize a purchase. It is also not the same as a general supplier qualification or audit process, although supplier approval status may affect who receives the RFQ.

    How it appears in operations

    • A buyer sends an RFQ for machined parts based on a controlled drawing revision.

    • A contract manufacturer issues an RFQ to outside processors for plating, heat treatment, or special processing.

    • A sourcing team compares RFQ responses for price, lead time, and compliance with specification requirements before issuing a purchase order or contract.

    Common confusion

    RFQ vs. RFP: An RFP, or Request for Proposal, is commonly used when the buyer needs a broader solution, approach, or technical proposal, not just a quote for a well-defined requirement.

    RFQ vs. RFI: An RFI, or Request for Information, is generally used earlier to gather market or supplier information before formal quoting.

    RFQ vs. PO: A PO, or purchase order, is the actual buying document, not the request for pricing.

    Other meaning sometimes seen

    In some technical contexts, RFQ can also mean radio-frequency quadrupole, a device used in particle accelerator systems. That meaning is not the usual one in manufacturing procurement and enterprise operations.

  • Tiered Supplier

    A tiered supplier is a supplier classified by its position in a multi-level supply chain, usually based on how directly it supplies an original equipment manufacturer, prime contractor, or final assembler.

    In manufacturing, a Tier 1 supplier typically supplies directly to the OEM or prime. A Tier 2 supplier supplies a Tier 1 supplier, and a Tier 3 supplier supplies a Tier 2 supplier. The same company can occupy different tiers depending on the product, program, or customer relationship.

    Tiered supplier structures are commonly used in procurement, supplier quality, materials planning, traceability, and supply chain risk management. They help describe where parts, materials, outside processing, or technical data move across the extended supply base.

    A supplier tier is not the same as a supplier rating, approval status, or quality score. It describes supply chain position, not necessarily performance, risk level, or certification status.

  • How are RFQ decisions documented for AS9100 and customer audits?

    RFQ decisions are usually documented through a controlled quote or contract review record that shows how requirements were evaluated, what risks or exceptions were identified, who approved the decision, and what was finally offered to the customer. For AS9100 and customer audits, the expectation is generally not just that a quote exists, but that you can show objective evidence of the review and decision path.

    In practice, an auditor will usually look for evidence that your organization reviewed applicable requirements before committing. That commonly includes technical requirements, delivery expectations, capacity, special processes, quality clauses, customer flow-downs, configuration or revision status, and any assumptions or exclusions used in the quote. If the RFQ was declined, many organizations also retain the reason for no-bid when that is part of their process discipline or risk management.

    What the documentation usually needs to show

    • The RFQ or customer request received, including revision level and date.

    • The requirements reviewed, including drawings, specifications, statements of work, quality clauses, and customer-specific terms where applicable.

    • Any identified risks, constraints, assumptions, exclusions, or open questions.

    • Cross-functional input where needed, such as sales, engineering, quality, supply chain, operations, or program management.

    • The decision outcome: bid, no-bid, conditional bid, or quote revision.

    • The approver(s), approval date, and the version of the information approved.

    • Traceability from the review to the issued quote, and later to the contract, purchase order, or order acceptance if awarded.

    If your process includes re-reviews after customer changes, that should also be documented. A common audit failure mode is having a clean initial review but weak evidence that revised requirements, changed quantities, expedited delivery dates, or updated drawings were re-evaluated before acceptance.

    What format is acceptable

    There is no single required format. Documentation may live in ERP, CRM, QMS, a quoting system, PLM-linked workflows, or controlled forms and attachments. What matters is that the record is controlled, retrievable, attributable to responsible roles, and consistent with your documented process.

    Email alone is usually not strong enough unless your organization has a controlled way to capture, retain, approve, and trace those messages as part of the official record. In many plants, email contains important context, but the auditable record is a formal contract review, quote approval workflow, or linked change-controlled form.

    What auditors typically test

    Auditors commonly sample from a released order backward. They may ask you to show:

    • How the original RFQ was reviewed before the quote was issued.

    • Whether customer and regulatory requirements were identified and flowed into planning.

    • How exceptions, assumptions, or capability gaps were handled.

    • Whether quote revisions and order changes were re-reviewed.

    • Whether the final accepted scope matches what was reviewed and approved.

    If the organization cannot link the quote decision to the accepted contract terms, manufacturing plan, or quality requirements, the issue is usually traceability, not just missing paperwork.

    Brownfield reality

    In brownfield environments, RFQ decisions are often spread across CRM, ERP, spreadsheets, email, shared drives, and tribal knowledge. That is common, but it creates audit risk. The main problem is not that you use multiple systems. The problem is weak evidence trails, inconsistent revision control, unclear ownership, and manual re-entry that breaks traceability.

    For that reason, full replacement is often not the best answer. In regulated, long-lifecycle environments, replacing quoting, ERP, QMS, or planning systems can trigger significant qualification effort, validation work, integration risk, and operational disruption. Many organizations get better results by adding a controlled review workflow and evidence model around existing systems, then improving linkage over time.

    A workable approach is often to define a minimum required RFQ review record, identify the system of record for each data element, and enforce approval, revision handling, and retention rules through change control. That is usually more realistic than trying to force a single new platform across every plant and legacy process.

    Bottom line

    RFQ decisions for AS9100 and customer audits should be documented in a controlled, traceable review record that shows requirements review, risk and exception handling, approvals, revisions, and linkage to the final commercial and operational commitment. The exact mechanism can vary, but if your evidence depends on scattered inboxes, undocumented judgment, or manual file hunting, it is unlikely to hold up consistently under audit.

  • 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.

  • approved vendor list

    An approved vendor list commonly refers to a controlled list of suppliers that an organization has evaluated and authorized for purchasing specific goods or services. In manufacturing and regulated operations, it is typically part of supplier control, procurement, and quality system processes.

    The list usually identifies which vendors are permitted for defined categories, sites, materials, or services. Approval may be based on factors such as qualification status, quality history, documentation, risk review, commercial review, or required certifications. Inclusion on the list does not usually mean a supplier is approved for every item or every use case.

    How it is used in operations

    In practice, an approved vendor list is often maintained in ERP, QMS, supplier management, or purchasing workflows. Buyers, planners, and quality teams may use it to determine whether a supplier can be selected for a purchase order, outsourced process, or recurring material source.

    • Raw material suppliers may be approved for specific material families.
    • Contract processors may be approved for defined special processes or service scopes.
    • Indirect vendors may be approved for maintenance, calibration, logistics, or other support services.

    The list may also be linked to supplier qualification records, audits, scorecards, risk assessments, and document control. In some organizations, approvals have statuses such as approved, conditional, suspended, or disqualified.

    What it includes and excludes

    An approved vendor list includes suppliers that have been formally accepted under the organization’s internal controls. It does not by itself define contract terms, performance guarantees, or regulatory approval. It is also not the same as a complete supplier master, because a supplier can exist in a system record without being approved for active sourcing.

    Common confusion

    Approved vendor list is often confused with approved manufacturer list or approved supplier list. These terms are sometimes used interchangeably, but some organizations distinguish them:

    • Approved vendor list: often focuses on the entity from which the organization buys.
    • Approved supplier list: a broader term that may include manufacturers, distributors, processors, and service providers.
    • Approved manufacturer list: usually focuses on the original producer of a part or material, not the reseller.

    It is also different from a preferred supplier list. Preferred suppliers are commonly favored for commercial or strategic reasons, while approved suppliers meet the minimum internal criteria for allowed use.

  • Stockist

    A stockist is an organization or business unit that holds, manages, and supplies inventory, typically on behalf of manufacturers, distributors, or end customers. In industrial and regulated manufacturing environments, a stockist often acts as an intermediate inventory holder, ensuring that parts, materials, or consumables are available when required for production or maintenance activities.

    Core characteristics of a stockist

    In the context of manufacturing and industrial supply chains, a stockist commonly:

    • Maintains physical inventory of parts, materials, or products, often across multiple locations or regions.
    • Receives goods from one or more suppliers and stores them under defined storage, handling, and identification controls.
    • Issues or ships items to manufacturers, maintenance organizations, or downstream customers based on orders, schedules, or contract terms.
    • Tracks inventory balances, lot or batch information, and basic traceability data, sometimes integrated with the customer’s ERP or MES.
    • May perform limited value-added services such as repackaging, labeling, or basic inspections according to agreed procedures.

    A stockist can be:

    • An independent third-party distributor or logistics provider.
    • A business unit within a larger enterprise that manages centralized inventory for multiple plants or service centers.
    • A local or regional warehouse that serves as a buffer between global suppliers and point-of-use locations on the shop floor.

    Operational role in regulated manufacturing

    In regulated industries such as aerospace, defense, or medical device manufacturing, stockists are often part of the controlled supply chain. Their activities may include:

    • Maintaining records that support traceability back to original manufacturers, including lot, serial, and certificate references.
    • Handling documentation such as certificates of conformity, material test reports, and shelf-life or environmental storage data.
    • Aligning their inventory control processes with customer quality and procurement requirements, including labeling and segregation of conforming and nonconforming stock.
    • Interfacing electronically with customer systems for advanced shipment notices, consignment stock visibility, or replenishment signals.

    What a stockist is not

    • It is not a manufacturer of the goods it holds, although a stockist may belong to the same corporate group as a manufacturer.
    • It is not typically responsible for product design, regulatory approvals, or process validation of the items stored.
    • It is not necessarily a full-line distributor offering technical application support, though some stockists may provide limited advisory services.

    Common confusion

    Stockist vs distributor: In many regions, the terms are used interchangeably. In some organizations, a distributor emphasizes commercial responsibilities (sales, market coverage), while a stockist emphasizes the inventory-holding and fulfillment function.

    Stockist vs warehouse: A warehouse is a physical facility. A stockist refers to the entity or function responsible for owning or controlling the inventory and managing its flow, which may use one or more warehouses.

    Examples in manufacturing workflows

    • Aerospace OEMs using regional stockists to hold standard hardware (fasteners, fittings) near multiple assembly plants, with inventory data integrated to the ERP for planning and MRP.
    • Maintenance, repair, and overhaul (MRO) operations sourcing spare parts from approved stockists that can provide required documentation and traceability for each lot or serial number.
    • Manufacturers using a consignment model where a stockist holds material on-site at the plant, with ownership transferred when parts are consumed in production.

  • system and services acquisition

    System and services acquisition commonly refers to the structured process an organization uses to plan, procure, validate, and accept systems and services. In industrial and regulated environments, this includes IT systems, OT assets, software platforms such as MES or ERP, cloud services, and vendor-managed solutions.

    The focus is on making sure that what is acquired is clearly specified, evaluated, and brought into operation under defined technical, security, quality, and compliance requirements. It typically covers:

    • Defining business, technical, security, and regulatory requirements for new systems and services
    • Evaluating suppliers and proposed solutions against those requirements
    • Including appropriate clauses in contracts for support, updates, data handling, and access control
    • Performing security, quality, and interoperability reviews before approval
    • Planning deployment, validation, and acceptance testing
    • Documenting ownership, responsibilities, and lifecycle expectations

    In manufacturing and regulated operations

    In manufacturing, system and services acquisition typically applies when organizations select and onboard:

    • Industrial control systems, PLCs, HMIs, and associated network components
    • Manufacturing IT platforms such as MES, LIMS, QMS, and historian systems
    • Cloud or SaaS services used for production scheduling, maintenance, or quality management
    • Third-party services such as remote monitoring, managed OT security, or data integration services

    Operationally, the acquisition process helps ensure that new systems and services can be integrated with existing OT/IT infrastructure, support required audit trails and data retention, and respect plant safety, cybersecurity, and change control practices.

    Relation to security and supply chain controls

    In security and control catalogs such as NIST SP 800-53, system and services acquisition is treated as a control family governing how organizations specify, evaluate, and approve systems and services with security and supply chain risk in mind. This includes:

    • Requiring security and privacy capabilities in purchased products and services
    • Considering software supply chain risks when selecting vendors and components
    • Ensuring that contracts and service agreements address access, updates, and incident response
    • Requiring documentation needed for audits, traceability, and configuration management

    In brownfield manufacturing environments, these practices are often applied when upgrading legacy OT systems, adding remote connectivity, or onboarding new software suppliers that interact with production networks.

    Common confusion

    • Not the same as general procurement: System and services acquisition is a focused subset of procurement that emphasizes technical, security, lifecycle, and compliance requirements, rather than only price and commercial terms.
    • Different from vendor management: Vendor management looks at the broader relationship with a supplier over time. Acquisition focuses on the specific process of defining, selecting, and accepting particular systems or services.

  • purchase order (PO)

    A purchase order (PO) is a formal commercial document issued by a buying organization to a supplier that specifies the items, quantities, prices, and terms under which goods or services are to be provided. In industrial and manufacturing environments, the PO is the primary authorization for a supplier to deliver materials, components, tooling, services, or subcontracted operations.

    Key characteristics

    In regulated manufacturing and supply chain operations, a purchase order commonly includes:

    • Buyer and supplier identification and addresses
    • PO number and issue date
    • Line items with part numbers, descriptions, and revisions
    • Quantities, unit prices, and total value
    • Requested or required delivery dates and ship-to locations
    • Terms and conditions (payment, Incoterms, liabilities, etc.)
    • Quality and regulatory requirements (e.g., certificates, FAI/AS9102 note, special processes)
    • Reference to specifications, drawings, or work instructions

    The PO is typically created and managed in an ERP or procurement system and is often integrated with MRP, inventory, accounts payable, and supplier collaboration tools.

    Operational role in manufacturing

    Operationally, the purchase order:

    • Links demand to supply by tying MRP or planning requirements to specific external supplies
    • Provides the primary structure for tracking supplier commitments, delivery status, and backlog
    • Serves as the reference for receipts, inspections, and NCRs at incoming inspection
    • Feeds financial processes such as accruals, three-way match (PO, receipt, invoice), and costing
    • Often links to internal work orders or projects to maintain traceability of purchased content into finished goods

    In many aerospace and regulated environments, detailed line-level PO data (part, revision, lot, required certs) is used to maintain traceability and to verify that supplier deliveries meet contractual and regulatory requirements.

    PO in backlog and risk visibility

    For supply chain and capacity management, purchase orders provide the structure against which suppliers communicate confirmations, updated delivery dates, capacity constraints, and change notifications. Backlog execution risk and material shortage risk are typically assessed by comparing supplier-confirmed PO data to internal demand dates, work orders, and program schedules.

    What a purchase order is not

    • It is not an invoice. The supplier invoice is a billing document raised after shipment or service, often matched back to the PO.
    • It is not a contract in the broader legal sense, although it usually incorporates or references contractual terms.
    • It is not a work order. Internal work orders govern in-plant manufacturing steps, whereas POs govern external procurement and services.

    Common confusion

    • PO vs. purchase requisition (PR): A purchase requisition is an internal request to buy; the purchase order is the external document sent to the supplier.
    • PO vs. schedule agreement/release: Some organizations use long-term agreements with periodic releases instead of discrete POs for each order; the release still functions similarly to a PO line operationally.