Connect981 – Content Dev

FAQ Tag: change control

  • What MES data do I need before starting AI projects in aerospace?

    You do not need a perfect MES to start AI projects in aerospace. You do need data that is trustworthy enough for a narrow, well-defined problem and traceable enough that engineering, quality, and operations can review how the output was produced.

    In practice, the best starting point is not “all MES data.” It is the smallest data set that supports one operational question, such as predicting rework risk on a process step, identifying likely bottlenecks, or prioritizing quality review queues.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Minimum MES data foundation

    For most aerospace manufacturing use cases, the minimum useful MES data set includes:

    • Work order and routing history
      Operation sequence, work center, planned versus actual step completion, hold events, rework loops, and dispatch status.

    • Part, serial, and lot traceability
      Part number, revision, serial number or lot, parent-child relationships where applicable, and material or component consumption records.

    • Timestamps with consistent event meaning
      Start, stop, queue, move, hold, release, inspection complete, and close timestamps. If timestamp semantics vary by area or by shift, AI outputs will be difficult to trust.

    • Quality outcomes
      Inspection results, pass-fail dispositions, defect codes, NCR links, rework records, scrap events, and disposition timing.

    • Operator and resource context
      Work center, machine or asset identifier, shift, certification or role if allowed by policy, and major tooling context. This matters when trying to separate product effects from resource effects.

    • Configuration and revision context
      Routing revision, work instruction revision, process plan revision, and where possible the effective configuration at the time of execution.

    • Basic master data stability
      Consistent part numbers, operation codes, defect codes, reason codes, and asset identifiers. If names and codes change without control, the model may learn noise instead of process behavior.

    What usually matters more than volume

    For aerospace, data quality and context usually matter more than raw volume. A smaller, cleaner execution history with stable identifiers and strong genealogy is more useful than a large MES extract full of missing timestamps, free-text workarounds, and uncontrolled code changes.

    You should expect problems if any of the following are true:

    • The MES event model changed over time and no one mapped old and new meanings.

    • ERP, PLM, QMS, and MES disagree on part revision, operation naming, or status definitions.

    • Rework is recorded inconsistently or outside the MES in spreadsheets, email, or disconnected QMS workflows.

    • Inspection outcomes are captured, but not linked reliably to the exact operation, configuration, or serial number.

    • Important process changes were made without clean change control metadata, making before-and-after comparisons misleading.

    Data readiness by AI use case

    The data needed depends on the use case.

    • Bottleneck and flow analysis
      You mainly need event timestamps, routing states, queue and hold reasons, and work center context.

    • Yield, scrap, or rework prediction
      You need genealogy, operation history, inspection outcomes, defect codes, rework loops, revision context, and enough historical examples of failures to train against.

    • Operator guidance or anomaly detection
      You may also need machine, sensor, or test data outside MES, plus digital work instruction usage and exception history.

    • Scheduling or dispatch recommendations
      You usually need MES plus ERP and planning context, because MES alone rarely contains all constraints, material status, outside processing dependencies, or program priorities.

    So the honest answer is that MES data alone is often necessary but not sufficient.

    What is enough to start

    A practical starting threshold is usually:

    • One clearly defined business question

    • Six to eighteen months of reasonably consistent execution history, if product and process conditions were stable enough during that period

    • Reliable identifiers linking work orders, operations, parts, serials or lots, and quality events

    • A known system of record for each critical field

    • Documented data gaps and business rules, rather than pretending the data is cleaner than it is

    That said, the required history length depends on event frequency and process stability. High-mix, low-volume programs may not produce enough repeatable examples for some supervised models. In those environments, analytics, rules, and constrained anomaly detection may be more realistic than ambitious predictive AI.

    Brownfield reality in aerospace

    In aerospace plants, MES data readiness is usually limited by coexistence issues, not just MES functionality. Many sites run mixed MES, ERP, PLM, QMS, and homegrown systems with different data models and years of integration debt. Important execution evidence may be split across digital travelers, test systems, inspection tools, and manual records.

    That is why full replacement is rarely the right prerequisite for AI. Replacing MES or surrounding systems first often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the long lifecycle of equipment and regulated processes. A narrower approach is usually safer: map the data needed for one use case, establish traceable extracts, validate logic with process owners, and expand only after the outputs are reviewable and useful.

    Governance you should have before production use

    Before using AI outputs operationally, you should have:

    • Clear data lineage from source systems to features and outputs

    • Change control for mappings, code sets, and model versions

    • Review procedures for questionable recommendations or anomalies

    • Defined handling for missing, late, or corrected records

    • Validation appropriate to the intended use and system impact

    This does not guarantee acceptance or compliance outcomes, but without these controls, AI results are hard to defend in a regulated environment.

    Bottom line

    Start with MES data that can reliably answer one operational question: event history, routing context, genealogy, quality outcomes, revision context, and stable timestamps. If those links are weak, fix the data path before scaling AI. If those links are strong, you can begin with a bounded use case even in a brownfield aerospace environment.

  • Is AS9102 mandatory for all aerospace first articles?

    AS9102 is not automatically mandatory for every aerospace first article. It becomes mandatory when it is explicitly required by one or more of the following:

    • Customer contract or purchase order terms
    • Customer quality clauses or supplier quality requirements
    • Prime or Tier 1 flowdown requirements (e.g., via SQAR, Q-notes, S-specs)
    • Your own QMS procedures that specify AS9102 as the standard FAI method

    AS9102 is a widely adopted standard FAI format in aerospace, but it is still a standardized method, not a universal legal mandate. Some OEMs and defense programs require fully compliant AS9102 Forms 1, 2, and 3 for defined scope (e.g., all flight hardware, safety critical, or key characteristics). Others accept an equivalent FAI structured differently, as long as the information content meets their requirements.

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    When AS9102 is typically required

    • New part introduction on aerospace/defense programs that reference AS9100 and AS9102
    • First build from a new supplier, site, or production line
    • Configuration changes affecting fit, form, or function, when customer FAI re-trigger rules apply
    • After major process changes (new machine, facility move, new manufacturing route) when required by contract or QMS

    In these situations, the contract or OEM quality specification often calls out AS9102 explicitly, or references it as the default unless a different FAI format is agreed in writing.

    When you might not use AS9102 format

    There are common cases where a strict AS9102 form set is not used, even in aerospace:

    • Internal FAIs for process validation where your QMS defines a different template but equivalent content
    • Customer-specific FAI formats that differ from AS9102 (e.g., proprietary forms or portal-based workflows such as Net-Inspect configurations)
    • Legacy programs started before AS9102 adoption, still running under older FAI conventions
    • Non-flight or non-critical parts where the customer has not flowed down AS9102 or any formal FAI requirement

    In these scenarios, what is mandatory is whatever your customer contract, applicable quality specs, and internal procedures say. You can be audited against your commitments, but not automatically against AS9102 if it is never invoked.

    Brownfield reality and coexistence with other requirements

    In most established aerospace plants, you will see multiple FAI regimes coexisting:

    • Some programs requiring strict AS9102 compliance
    • Some legacy or commercial programs using older or simplified FAI formats
    • Some customer portals (e.g., Net-Inspect or OEM tools) that map to AS9102 concepts but use different data structures

    This mix is typical in brownfield environments with long product lifecycles and many OEMs. Attempts to force a single, universal FAI format can run into resistance due to contractual constraints, qualification burden, and revalidation cost. Often the practical approach is to standardize data content and traceability while still producing the specific form or portal output each customer requires.

    Key tradeoffs and constraints

    • Compliance risk: If a contract or quality clause calls out AS9102, deviating from that format without written customer approval is a risk and can surface in audits.
    • Internal consistency: If your QMS says “we perform AS9102 FAIs” in broad terms, auditors will expect evidence that FAIs follow the standard, not a patchwork of partial forms.
    • Operational burden: Running AS9102 for every low-risk, non-critical part can add paperwork without commensurate value, especially in high-mix, low-volume environments.
    • System limitations: Legacy MES, ERP, or PLM may not natively support AS9102 structures, so digital FAI often involves bolt-on tools or manual spreadsheets unless you invest in integration and validation.

    Any change from non-AS9102 FAI to AS9102 (or vice versa) across programs should go through formal change control, including updates to procedures, training, and, where relevant, validated systems.

    Practical guidance

    To determine whether AS9102 is mandatory for a given first article:

    1. Review the contract, PO, and referenced quality clauses for explicit AS9102 or FAI language.
    2. Check the customer’s supplier quality manual / specifications for FAI expectations and re-trigger rules.
    3. Confirm your internal QMS and work instructions: do they specify AS9102, an equivalent FAI, or program-specific rules?
    4. Align with your customer quality representative before deviating from AS9102 on parts where expectations are unclear.

    AS9102 is widely accepted because it standardizes expectations and evidence. But it is only mandatory where it has been made a requirement by contract, customer flowdown, or your own documented processes.

  • What are the main business benefits of ISO 9001 certification?

    ISO 9001 certification can provide real business benefits, but only when the quality management system (QMS) is genuinely used to run the operation, not treated as paperwork for auditors. In regulated and aerospace-grade environments, the main benefits come from better control of processes, clearer accountability, and more predictable outputs across a complex system of plants, suppliers, and IT.

    1. More consistent quality and fewer surprises

    ISO 9001 pushes you to define, control, and monitor key processes. When this is done well, you typically see:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • More consistent part conformance and documentation quality across shifts, sites, and suppliers.
    • Earlier detection of issues through defined checks, reviews, and internal audits.
    • Less variation driven by tribal knowledge or individual workarounds.

    The impact depends on how seriously you treat process definition, training, and change control. A certificate alone does not reduce nonconformances or escapes.

    2. Structured approach to risk and problem solving

    ISO 9001 requires risk-based thinking, corrective actions, and structured management review. Done properly, this can lead to:

    • Clearer prioritization of risks that can impact product quality or delivery.
    • More disciplined root cause analysis and closure of corrective actions, instead of recurring fixes.
    • Documented decision-making that is easier to defend to customers and regulators.

    The business benefit appears only if leadership actually uses these mechanisms to make decisions, not just to populate audit binders.

    3. Better customer confidence and access to business

    Many OEMs and tier-1s expect ISO 9001 (or sector-specific variants like AS9100) as a baseline. Certification can:

    • Reduce friction in supplier qualification and RFQ processes.
    • Improve customer confidence in your ability to control quality and maintain traceability.
    • Support answers to customer audits and questionnaires with a recognized framework.

    Certification does not guarantee good audit outcomes or protect you from customer scrutiny, but it can shorten discussions and open doors where ISO 9001 is an explicit requirement.

    4. Clearer roles, documentation, and traceability

    ISO 9001 emphasizes documented processes, responsibilities, and records. In practice, this can enable:

    • Less ambiguity over who owns which process, metrics, and approvals.
    • Stronger document control and version governance for procedures, work instructions, and specifications.
    • More reliable evidence trails for product history, changes, and decisions.

    These benefits are critical in environments with long equipment lifecycles, multiple revisions, and frequent audits. The value depends on how well your QMS is integrated into daily workflows and IT systems, not just that documents exist.

    5. Foundation for continuous improvement and cost reduction

    ISO 9001 does not prescribe lean or Six Sigma, but it establishes a framework for continuous improvement. Over time, this can support:

    • Reducing cost of poor quality (scrap, rework, returns, concessions) through data-driven corrective actions.
    • Improving throughput and on-time delivery by stabilizing and standardizing processes.
    • Making improvement projects auditable and repeatable across sites.

    The magnitude of savings depends heavily on data quality, measurement systems, and whether continuous improvement is truly embedded in operations, not just a quality department activity.

    6. Stronger governance over change and long lifecycle assets

    ISO 9001 requires formal control of design and process changes. In regulated, long-lifecycle environments, this often delivers:

    • Reduced risk of uncontrolled changes affecting certified products, tooling, or software.
    • Better alignment between engineering changes, production, and quality records.
    • More predictable impacts on validation, requalification, and documentation when processes or systems change.

    This is especially important when you upgrade MES/ERP/QMS components or modify legacy equipment that has been in service for decades. A disciplined ISO 9001 change process can prevent misaligned updates that cause line stoppages or audit findings.

    7. Coexistence with existing systems and brownfield reality

    In most plants, ISO 9001 is layered on top of a mix of legacy MES, ERP, PLM, and paper-based systems. The benefits depend on how you implement the standard in this brownfield context:

    • Integration over replacement: Trying to replace all systems to “be ISO-compliant” is rarely viable due to qualification burden, validation cost, and downtime risk. It is usually more effective to integrate existing systems into a coherent QMS framework and close the gaps with targeted changes.
    • Realistic traceability: ISO 9001 expects you to maintain appropriate records and traceability. How far you go (lot-level, serial-level, full genealogy) must align with your sector requirements and with what your current systems can reliably support.
    • Validation and change control: Any IT or process changes you make to support ISO 9001 (e.g., new QMS modules, digital work instructions) should go through formal validation and change control, or you risk trading one set of problems for another.

    Plants that treat ISO 9001 as a way to rationalize their existing system landscape and clarify interfaces usually see more benefit than those that launch large, disruptive replacement programs justified primarily by certification goals.

    8. Limitations and common failure modes

    ISO 9001 certification is not a guarantee of quality, compliance, or safety performance. Common failure modes include:

    • A well-documented QMS that operators do not actually follow on the shop floor.
    • Processes tailored to pass audits rather than to control real operational risk.
    • Certificates used as marketing proof without corresponding investment in training, data, or system integration.

    To realize business benefits, leadership has to use ISO 9001 as a management system: align KPIs with the QMS, use audit findings to drive meaningful improvements, and ensure IT/OT changes support the processes described in the QMS.

    In summary, ISO 9001 certification can support improved consistency, customer trust, and structured improvement, but the business payoff is determined by implementation quality, integration with existing systems, and ongoing governance, not by the certificate itself.

  • How long should CAPAs remain open before escalation?

    There is no universal maximum time that a CAPA can stay open before escalation. The escalation trigger has to be defined in your quality system and justified by risk, process complexity, and resource reality. Regulators will expect you to follow your own procedure consistently and explain why it makes sense.

    Typical timeframes used in regulated environments

    While numbers vary by company and product risk, many sites use time-based triggers like:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Low/medium risk CAPAs: 60 to 90 days to implementation, with earlier checkpoints.
    • High risk / patient safety / regulatory impact CAPAs: 30 to 60 days for containment and critical actions, sometimes with formal weekly review.
    • Effectiveness checks: Often scheduled 30 to 180 days after implementation; these have their own aging rules.

    The exact numbers should be documented in your CAPA SOP, not improvised case by case.

    Use tiered escalation instead of a single deadline

    Rather than one “max age,” most mature systems define staged escalation based on target due dates:

    • Planned due date: Set per CAPA step (investigation, root cause, implementation, effectiveness check), aligned to risk.
    • Early warning (e.g., 14 days before due date): Reminder to owner and functional manager.
    • First escalation (e.g., at due date missed): Escalate to department head; documented justification and revised plan required in the CAPA record.
    • Second escalation (e.g., 30 days late or crossing a defined “max age” threshold): Escalate to site quality leadership and possibly management review.
    • Critical escalation (for high risk CAPAs or repeated slippage): Escalate to executive leadership, with explicit risk assessment of operating with CAPA open.

    This approach recognizes that a complex, multi-site CAPA may legitimately take longer than a simple local corrective action, while keeping visibility on aging items.

    Risk-based timelines are expected

    Escalation criteria should be explicitly tied to risk, not just calendar age. Consider:

    • Severity of the underlying issue (e.g., safety, regulatory, business continuity).
    • Detectability and occurrence (e.g., how likely is recurrence while the CAPA is open).
    • Scope and complexity of changes (multiple lines, suppliers, or software/automation changes usually need longer and more formal change control).

    High risk CAPAs generally warrant shorter timelines, stricter monitoring, and faster escalation than low risk, localized issues.

    What auditors and regulators actually look for

    Auditors rarely look for a specific “number of days” as a rule that applies everywhere. Instead, they assess whether:

    • Your CAPA procedure defines clear expectations and escalation rules.
    • You follow your own rules and document deviations and justifications.
    • Risks are controlled while CAPAs are open (containment, interim controls, additional inspection or testing).
    • Chronic aging CAPAs are visible in management review and trigger systemic fixes (e.g., resourcing, prioritization, training).

    Inconsistent behavior is usually a bigger problem than a long but justified and documented CAPA timeline.

    Handling long-duration or complex CAPAs

    In industrial and aerospace-grade environments, some CAPAs legitimately take many months because they involve:

    • Changes to qualified equipment or validated software.
    • Updates across multiple plants, suppliers, or ERP/MES/QMS integrations.
    • Customer approvals, contract changes, or formal requalification.

    Closing these too quickly to “hit a date” can create new nonconformances. For long, complex CAPAs, you can mitigate aging by:

    • Breaking work into phased CAPAs or sub-actions with their own due dates.
    • Maintaining strong interim controls (e.g., 100% inspection, additional signoffs, temporary process limits).
    • Documenting why a longer timeline is necessary (e.g., shutdown windows, validation testing, supplier lead times).
    • Reviewing progress in formal governance forums like CAPA review boards or management review.

    This is particularly important in brownfield sites where changing legacy MES/ERP, test equipment, or automation carries downtime, validation, and integration risk.

    Practical minimums for defining your own rules

    When you write or refine your CAPA SOP, you should at least:

    • Define target timelines per CAPA phase (e.g., investigation, root cause, action plan, implementation, effectiveness check).
    • Define risk-based categories (e.g., critical, major, minor) with different expectations.
    • Specify time-based aging thresholds for reminders and escalations (e.g., 30/60/90 days, adapted to your environment).
    • Require a documented justification and revised plan any time a due date is extended.
    • Ensure your eQMS, MES, or tracking tools can report CAPA aging and escalation status accurately.

    Whatever thresholds you choose, they should be achievable with your current staffing, system integration, and shutdown windows. Overly aggressive “paper” timelines that are routinely violated often look worse during audits than a realistic, risk-justified plan.

    Bottom line

    CAPAs should not remain open indefinitely, but there is no single mandated maximum age. Use risk-based, phase-specific targets with clear, staged escalation and documented justifications for any delays. In complex, regulated, and brownfield environments, longer timelines can be acceptable if interim risk controls are strong and governance is disciplined.

  • What types of controls does AS9100 expect for counterfeit parts prevention?

    AS9100 expects you to implement a documented, risk-based counterfeit parts prevention process that is integrated into your quality management system. The standard does not prescribe a single method, but it does expect a coherent set of controls across supplier management, purchasing, receiving, production, and nonconformance handling.

    1. Documented counterfeit parts prevention process

    AS9100 requires you to define, maintain, and control a counterfeit parts prevention process or procedure. At a minimum, it should:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Define what your organization considers a counterfeit or suspected counterfeit part (aligned with AS9100 and any customer/contract definitions).
    • Describe responsibilities across quality, supply chain, engineering, and production.
    • Specify where and how controls apply: supplier selection, purchasing, receiving, in-process, inventory, service/repair, and disposal.
    • Describe how to escalate, investigate, and disposition suspected counterfeit parts using your existing nonconformance and CAPA processes.
    • Include how you maintain records to provide objective evidence during audits.

    2. Supplier evaluation and approval controls

    AS9100 expects you to reduce counterfeit risk by controlling who you buy from and under what conditions. Typical controls include:

    • Approved supplier list (ASL): Criteria for adding and maintaining suppliers, with stronger criteria for high-risk categories (electronic components, hardware, high-value or safety-critical items).
    • Preference for original sources: Using original component manufacturers (OCMs), original equipment manufacturers (OEMs), or their authorized distributors whenever feasible.
    • Heightened controls for brokers/independent distributors: Additional verification, audits, or test requirements when you must use non-authorized sources.
    • Supplier performance monitoring: Tracking quality history, documentation issues, and any counterfeit-related incidents as part of supplier scorecards or periodic reviews.
    • Flowdown requirements: Requiring suppliers to maintain their own counterfeit parts prevention controls and to flow those requirements down their supply chains when applicable.

    In brownfield environments this usually means tightening criteria and documentation around an existing ASL, not replacing supplier systems outright. Changes typically have to move through established change control and supplier qualification processes.

    3. Purchasing and contract controls

    AS9100 expects purchasing documents to include requirements that reduce counterfeit risk. Common elements are:

    • Clear sourcing requirements: Specifying OCM/OEM or authorized distribution channels where required.
    • Traceability requirements: Mandating certificates of conformity, manufacturer certificates, test reports, and lot/date codes as appropriate.
    • Change notification: Requiring suppliers to notify you of substitutions, alternate sources, or changes in distribution channels.
    • Right of access and audit: Enabling you (and sometimes customers or regulators) to review the supplier’s counterfeit controls.
    • Suspected counterfeit reporting obligations: Expecting the supplier to cooperate in investigations and reporting if suspect parts are identified.

    Practically, this often involves updating PO templates and ERP purchasing data, plus retraining buyers on when to invoke stricter clauses based on part criticality and risk.

    4. Receiving inspection and verification controls

    AS9100 expects you to verify that incoming product is authentic and conforms to requirements, with the level of scrutiny based on risk. Typical controls include:

    • Document verification: Checking certificates of conformity, manufacturer certificates, lot/date codes, and serial numbers for consistency with POs and specifications.
    • Visual inspection: Looking for signs of tampering, re-marking, inconsistent packaging, or physical anomalies (especially for electronic components and hardware).
    • Sampling plans: Applying more stringent sampling and verification for high-risk sources or part families.
    • Enhanced testing where warranted: Electrical tests, X-ray, material analysis, or other methods for high-risk items when risk assessment justifies the cost and time.
    • Receiving holds: Preventing use of high-risk parts until required documentation and verification steps are completed.

    In brownfield plants this usually requires procedural updates and receiving training, plus some alignment with existing inspection and sampling plans. It may also require adjustments in ERP/MES receiving workflows to support holds and additional checks.

    5. Traceability and inventory controls

    AS9100 expects you to maintain sufficient traceability to detect, contain, and remove counterfeit or suspect parts. Controls typically include:

    • Lot and serial tracking: Maintaining traceability from received lot or serial numbers to work orders, assemblies, and shipped product for critical parts.
    • Segregated storage: Clearly separating conforming stock, suspect stock, and nonconforming/scrap so suspect material cannot be used by mistake.
    • Inventory transactions with genealogy: Recording movements between locations and work orders to support fast containment.
    • Controlled returns and reuse: Procedures for returns (RMA), teardown, and reuse to avoid reintroducing suspect material into inventory.

    In many regulated environments, full system replacement is not realistic due to validation and downtime constraints. Instead, organizations typically enhance traceability within existing ERP/MES/WMS platforms, use add-on tools for genealogy where needed, and strengthen procedures and labeling for suspect and nonconforming stock.

    6. Production and maintenance controls

    AS9100 expects counterfeit prevention to extend into production, repair, and overhaul activities:

    • Bill of material (BOM) and routing control: Ensuring only approved part numbers and sources are used for critical items.
    • Shop-floor verification: Work instructions or traveler checks for critical parts (e.g., verifying part/lot/serial against the traveler or build record).
    • Control of customer-furnished or repaired parts: Verifying authenticity and condition of customer-supplied items and parts returned for overhaul or repair.
    • Scrap and rework handling: Clear rules preventing scrapped or high-risk suspect parts from being reintroduced into production.

    These controls typically coexist with existing digital travelers, work instructions, and tool control in MES or paper-based systems. Organizations rarely replace core systems just to add counterfeit checks; they embed steps into existing workflows and validate those changes.

    7. Nonconformance, investigation, and disposition controls

    AS9100 expects suspected counterfeit parts to be managed through your nonconformance and CAPA processes, not treated as an informal side process. Typical controls include:

    • Immediate segregation and quarantine: Any suspected counterfeit part is clearly identified, removed from use, and placed in a controlled area.
    • Formal NCR / MRB process: Documenting the nonconformance, performing risk assessment, and deciding disposition via MRB in accordance with your QMS.
    • Root cause and corrective action: Using structured methods (e.g., RCA, 8D) to address why the counterfeit part entered your system (supplier, purchasing, inspection, design, or system gap).
    • Communication and reporting: Notifying affected customers and, where applicable, industry reporting bodies in line with contractual and regulatory requirements.
    • Documented disposal: Ensuring confirmed counterfeit parts are destroyed or rendered unusable and cannot re-enter the supply chain.

    Because nonconformance and CAPA systems are usually deeply embedded and validated, organizations tend to extend those systems for counterfeit scenarios rather than deploy a separate tool. Careful change control and validation are important if you modify digital NCR/MRB workflows.

    8. Training and awareness

    AS9100 expects personnel who can influence counterfeit risk to be trained and aware of their role. Typical practices include:

    • Role-specific training: For buyers, receiving inspectors, warehouse staff, engineers, and production supervisors.
    • Recognition of red flags: Visual cues, documentation anomalies, unusual pricing or lead times, and channel risks.
    • Reporting expectations: How to escalate if a part looks suspicious or documentation does not align with expectations.
    • Periodic refreshers: Integrating counterfeit awareness into ongoing competency and recurrent training schedules.

    9. Risk-based application and continual improvement

    AS9100 is explicit about risk-based thinking. Counterfeit controls should scale with risk, considering part criticality, market conditions, and supplier history. Auditors will typically look for:

    • Evidence that you have assessed which parts and suppliers present higher counterfeit risk.
    • Stronger controls where the risk and consequence of failure are higher.
    • Use of data from NCRs, supplier performance, and industry alerts to update controls over time.
    • Change control and, where relevant, validation of system or process updates related to counterfeit prevention.

    In long-lifecycle aerospace programs, any changes to traceability, supplier qualification, or digital workflows often require careful planning to avoid disrupting qualified configurations and to preserve evidence trails.

    10. Limits and dependencies

    AS9100 does not guarantee that counterfeit parts will never enter your supply chain. What it expects is:

    • A documented and implemented process appropriate to your risk profile and product types.
    • Integration of counterfeit prevention into your existing QMS, supplier management, and traceability processes.
    • Objective evidence that controls are followed, monitored, and improved when issues occur.

    The exact mix of controls you adopt will depend on your supply base, product mix, digital maturity, and the practical constraints of your brownfield environment. Full replacement of core systems solely to add counterfeit controls is rarely necessary and often impractical given qualification and downtime risks; most organizations layer additional controls onto existing, validated processes and systems.

  • Can I build AI models directly on my MES database without a data warehouse?

    Yes, you can sometimes build AI models directly on an MES database without a data warehouse. For limited, read-only, non-critical analysis, it may be technically possible.

    But as a general production approach, it is usually not the right default in regulated manufacturing environments.

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    The issue is not whether it is possible. The issue is whether the MES database is the right place to source, govern, contextualize, validate, and retain the data needed for reliable models without creating operational or compliance risk.

    Why direct MES access is often a bad default

    • MES databases are optimized for execution, not analytics. Query patterns for model training and feature generation can compete with shop floor transactions, reporting jobs, and integrations. In brownfield plants, that can create performance instability at exactly the wrong time.

    • Raw MES data is rarely analytics-ready. It often contains missing context, inconsistent timestamps, event duplication, late-arriving records, code-value variations, and plant-specific workarounds. If the data model reflects years of operational exceptions, the model will learn those inconsistencies too.

    • You usually need data beyond MES. Useful manufacturing AI often depends on ERP, QMS, PLM, historian, maintenance, lab, inspection, and sometimes manual records. MES alone may not contain the full causal chain for quality, throughput, delay, or scrap outcomes.

    • Traceability and reproducibility become harder. If source records can change after transactions are corrected, backfilled, or reprocessed, you can struggle to prove which data version trained which model. That matters for change control, investigation, and revalidation.

    • Security and access boundaries get messy. Direct connections from data science tools or AI platforms into a production MES database can expand attack surface, increase privilege complexity, and blur IT and OT responsibilities.

    • Validation effort rises. In regulated settings, the more tightly the model depends on live transactional structures and brittle custom joins, the harder it is to validate behavior and manage changes safely.

    When direct MES-based modeling can be reasonable

    It can be reasonable if all of the following are true:

    • You are using a read replica, reporting replica, or export, not the primary production database.

    • The use case is narrow, such as exploratory analysis, anomaly screening, or a pilot on one line or process area.

    • The data needed is mostly contained in MES and does not require heavy cross-system reconciliation.

    • You have stable identifiers, timestamps, revision handling, and event semantics.

    • You can document data lineage, model inputs, refresh logic, and change control.

    • The model is advisory, not making autonomous release, quality, or safety decisions.

    Even then, most teams end up creating a curated analytical layer because direct use of MES data becomes hard to maintain as scope grows.

    What you need instead of a full warehouse

    A data warehouse is not the only option. If the concern is cost, time, or architecture overhead, there are middle paths:

    • Read replicas for isolated analytical workloads

    • Curated data marts for specific use cases like yield prediction or cycle time variance

    • Lakehouse patterns if you need lower-cost storage and mixed structured data

    • Feature stores or governed model input layers if multiple models will reuse the same signals

    • Historian plus MES plus QMS extracts for process-focused analytics

    The practical requirement is not a warehouse by name. It is a governed, query-safe, version-aware data layer that does not put the execution system at risk.

    Brownfield reality

    In many plants, the MES is only one piece of a mixed vendor stack with custom interfaces, manual workarounds, and long-lived equipment. That matters because AI projects often fail when teams assume the MES database is a complete and clean system of record. It usually is not.

    Full replacement of MES, ERP, PLM, or QMS just to make AI easier is often the wrong move in regulated, long lifecycle environments. Replacement programs can trigger major qualification work, validation cost, downtime risk, interface rewrites, and traceability disruption. A coexistence approach is usually more realistic: extract and govern the data you need while leaving execution systems in place.

    Practical decision rule

    If the use case is small, read-only, and non-critical, direct access to a replica of MES data may be acceptable.

    If the use case will influence production decisions at scale, combine multiple systems, or need repeatable validation and auditability, build a governed analytical layer first. That can be modest in scope, but it should exist.

    So the short answer is yes, but usually not directly against the live MES database, and usually not without some intermediate data architecture.