Yes, FAI requirements can be triggered automatically from ERP or MES, but only if the underlying data, business rules, and integrations have been designed and validated to support it. There is nothing in AS9102 that prevents automation, but it does require rigor around when and how an FAI is required, and where that logic is implemented.
Typical ways FAI triggers are automated
In most aerospace environments, automatic FAI triggers come from a combination of ERP, MES, and sometimes PLM/QMS signals:
- New part introduction: A new item or part number created in ERP/PLM is flagged as requiring a full FAI on first production work order.
- Engineering change / revision change: When PLM or ERP releases a new revision, a rule can set a “FAI required” flag if the change is classified as affecting form/fit/function, key characteristics, or safety/critical features.
- Routing / process change: MES recognizes a significant process or routing change (new operation, new machine group, new special process vendor) and sets FAI required for the next lot or work order.
- Supplier or site change: ERP or supplier management systems can trigger FAI when a part moves to a new supplier, a new manufacturing site, or a new special processor.
- Interruption in production: Some plants encode a rule that triggers a partial or full FAI if there has been a long lapse in production beyond a defined threshold.
In practice, these triggers are implemented as flags or attributes on the part, revision, routing, or work order that MES or an FAI application can detect to create or require an FAI package.
Where the logic usually lives
Different plants choose different systems as the “source of truth” for FAI triggers:
- ERP-centric: FAI required is driven off item master, revision, or sourcing/vendor data in ERP. Work orders carry a flag that downstream MES or inspection systems must honor.
- MES-centric: MES owns the FAI rules based on routing, operation, machine, and process history. ERP sends basic work-order and part data, and MES decides whether an FAI is required.
- PLM- or QMS-assisted: Classification of changes (e.g., whether a change requires FAI per engineering or quality) happens in PLM/QMS, which then marks the part/revision as FAI-required for execution systems.
What matters is clear ownership: only one system should be the master for FAI decision logic, and the others should consume that status, not redefine it.
Key dependencies and constraints
Automatic FAI triggering is only as reliable as the data and rules backing it:
- Change classification discipline: Someone must consistently classify changes (e.g., which ECNs or routing changes require FAI). If this is done informally in email or tribal knowledge, automation will be unreliable.
- Clean part and revision master data: Item numbers, revisions, and alternates must be consistently managed. If the same hardware appears under multiple part numbers or internal/Customer IDs, FAI logic can easily misfire.
- Machine, tooling, and process mapping: If FAI needs to respond to process changes (new machine, new fixture, new special process vendor), those must be modeled and maintained accurately in MES/ERP.
- Supplier and site information: For supplier FAIs, sourcing and vendor data in ERP must be current and unambiguous, including site/location codes.
- Integration quality: Interfaces between ERP, MES, PLM, QMS, and any FAI-specific system must be robust, with error handling, retries, and audit logs.
Without this maturity, automatic triggers can be worse than manual ones, because they give a false sense of completeness while missing edge cases.
Validation, traceability, and change control
In regulated aerospace environments, the automation itself has to be managed under change control and, where applicable, validated:
- Documented business rules: The exact FAI trigger logic (conditions, exceptions, part families, Customer-specific clauses) should be documented and controlled like any other quality-impacting process.
- Versioned configuration: FAI rules embedded in ERP/MES configuration, workflows, or code must be version-controlled so you can reconstruct which rule set applied to a given FAI.
- Testing and validation: Before going live, test scenarios should cover first builds, rev changes, process moves, supplier changes, and long gaps in production. Failures should be addressed before relying on automation.
- Auditability: It should be possible to show auditors why a given work order did or did not require FAI, with evidence of the rule that applied at that time.
Automating triggers does not remove the obligation to demonstrate that FAIs were performed when required; it only changes how the requirement is derived.
Brownfield and coexistence considerations
In brownfield environments with multiple ERPs, legacy MES, and mixed QMS tools, automatic FAI triggers usually have to coexist with manual steps and local workarounds:
- Multiple systems of record: Different programs or sites may have different masters (e.g., one site ERP-driven, another MES-driven). A uniform global rule may not be feasible.
- Legacy constraints: Older MES or ERP systems may not support fine-grained rules or additional flags. Workarounds (like dedicated item attributes or pseudo operations) may be required.
- Partial automation: Many plants start by automating a subset of triggers (e.g., new part and rev changes) and keep manual or QMS-driven approvals for more complex or ambiguous cases.
- Long equipment lifecycles: Replacing older systems solely to improve FAI triggering is rarely justifiable, given qualification burden, downtime risk, and integration complexity. Incremental integration and configuration changes are more common.
Because of these realities, it is typical to have automatic triggers feeding a queue of “candidate FAIs,” with quality engineering making final decisions for edge cases.
Common failure modes to watch for
Even with automation in place, you should plan for and monitor specific failure modes:
- Missed FAIs due to misclassified changes: Engineering marks a change as “no impact” when it actually affects form/fit/function, so no automatic FAI is triggered.
- Over-triggering FAIs: Rules that are too aggressive can trigger FAIs for every minor routing edit or parameter tweak, causing unnecessary delay and cost.
- Broken or lagging integrations: Interfaces fail silently and FAI flags are never updated, or are updated too late in the work-order lifecycle.
- Site-by-site rule drift: Local admins change rules to handle special cases, so different plants interpret FAI requirements differently for the same Customer.
- Manual overrides without traceability: Someone clears an FAI-required flag to keep production moving, but there is no documented rationale or approval.
Mitigation usually involves periodic review of FAIs vs. triggers, exception reports where FAIs were done without a recorded trigger (or vice versa), and governance on who can change rules.
Practical starting point
For most organizations, a pragmatic approach is:
- Document your FAI trigger rules per Customer and internal standard (what conditions require full, partial, or no FAI).
- Decide which system is the master for FAI required status (ERP, MES, or QMS/PLM) and document that ownership.
- Implement a small set of high-confidence automatic triggers (e.g., new part, new rev with impact flag, new supplier) and route them into your existing FAI process.
- Validate and audit the automation on a subset of programs before widening scope.
- Add more nuanced triggers (routing changes, machine moves, long gaps) only after the basics are stable.
Done this way, automatic FAI triggering from ERP or MES can reduce misses and manual tracking effort without creating unrealistic expectations of full automation or eliminating quality oversight.
