How do you standardize AS9102 workflows across multiple sites?

Standardizing AS9102 workflows across sites is mainly a process and governance problem, not a form template problem. The goal is a common data model, decision logic, and evidence trail, even if local plants stay on different MES, PLM, QMS, or inspection tools.

1. Start with a common AS9102 process model, not a single tool

Before touching systems, define what “standard” means:

• Scope: Which products, customers, and events trigger AS9102 (new part, revision change, change in source, change in process, change in manufacturing location, etc.).
• Process phases: E.g., trigger & classification → planning & ballooning → data collection → review & approval → submission → archiving & linkage to production.
• Roles & responsibilities: Engineering, quality, manufacturing, supplier quality, MRB, IT. Clarify who owns each decision and approval.
• Required artifacts: Ballooned drawing, characteristic list, control plan/routers, capability studies (if needed), raw inspection evidence, completed AS9102 Forms.
• Evidence rules: What must be retained, for how long, and where (QMS vs MES vs document control) to support AS9100 and customer audits.

This becomes the reference model that each site must map to, regardless of local tools.

2. Standardize the data, forms, and numbering

AS9102 already constrains the form layout, but multi-site consistency requires additional standardization:

• Single corporate data dictionary: Common field names, units, and codes for part family, revision, FAI level (full/partial), FAI reason, special characteristics, etc.
• Standard ballooning and characteristic schema: Clear rules for characteristic IDs, linking to CAD/PLM, and handling derived, key, and safety-critical features.
• Common FAI ID and revision logic: Define how FAI packages are numbered and revised when parts or processes change, and how superseded FAIs are marked across sites.
• Customer-specific variants: Explicitly document when a customer requires deviations from the base standard (e.g., Net-Inspect, custom characteristic codes) so sites don’t invent their own versions.

Without this, separate plants will produce AS9102-looking forms that are not consistently searchable, comparable, or auditable across the network.

3. Use a reference workflow and let sites map their tools into it

In brownfield environments, a realistic approach is:

1. Create a reference workflow: Document the ideal AS9102 process as a swimlane or BPMN-type diagram including triggers in PLM/ERP, routing in MES, and archiving in QMS/document control.
2. Map each site to the reference: For each plant, identify how their existing MES, PLM, QMS, CMM software, and Net-Inspect (if used) support each step or where they require manual workarounds.
3. Define site-specific deltas and compensating controls: E.g., one site uses digital travelers, another uses paper with scanning. Specify exactly how they still satisfy the standard evidence and approval requirements.
4. Set minimum requirements: For example, “no FAI can be approved without: linked ballooned drawing, complete characteristic list, traceable measurement source, and an electronic approval record.” Sites can exceed this, but not go below it.

This avoids a risky “rip and replace” across sites while still driving convergence toward one reference workflow.

4. Decide where the system of record lives

Multi-site confusion often stems from unclear system-of-record decisions:

• Engineering data & drawing authority: Typically PLM or document control. All FAIs should reference released, controlled revisions from this source.
• Production execution linkage: Often MES, digital travelers, or ERP routing. Define how an FAI requirement is visible on the traveler or work order and how FAI completion clears that requirement.
• FAI package & approvals: Either a central FAI solution, a QMS module, or a controlled repository with clear versioning and approval logs.
• Customer submission: If Net-Inspect or customer portals are used, clarify that these are submission channels, not the internal system of record.

Make this architecture decision explicitly and document it. Without it, every site will treat a different system as “the truth” for FAIs.

5. Build a cross-site governance and change control model

In regulated, long-lifecycle environments, the hidden work is governance:

• AS9102 process owner: Name a corporate owner (typically in quality/engineering) responsible for the standard and for approving any deviations.
• Cross-site council: A small group representing major plants that reviews proposed changes to the AS9102 standard, customer-specific requirements, and large tool changes.
• Formal change control: Changes to forms, workflows, or integrations go through documented change control, including impact assessment on validation, training, and legacy data.
• Periodic audits: Internal audits compare site practices to the reference workflow, checking triggers, evidence, approvals, and record retention.

This governance is usually more critical for long-term consistency than any specific software choice.

6. Integrate carefully with MES/PLM/QMS in a brownfield reality

Full replacement of MES, PLM, or QMS to “standardize AS9102” is usually unjustified in aerospace contexts due to:

• Qualification and validation burden: Replacing a validated system often requires re-qualification, re-validating interfaces, and re-training, which can disrupt production and audits.
• Downtime and cutover risk: Multi-site cutovers are high-risk, especially where AS9102 is gating customer deliveries.
• Integration complexity: FAIs sit at the intersection of CAD/PLM, ERP, MES, QMS, and sometimes customer portals; ripping out one element tends to expose more integration debt than anticipated.
• Asset and product lifecycles: Aerospace parts may run for decades; legacy FAIs and their links to historical process data often constrain what you can replace.

More pragmatic patterns include:

• Layer a standardized FAI solution on top: Use a central AS9102/FAI application or workflow that integrates lightly with site systems (PLM for drawing & BoM, ERP for part numbers and orders, MES/QMS for status and records).
• Use digital travelers as the bridge: At sites with digital travelers, embed FAI steps and link them to the central FAI package, so operators see consistent prompts even if back-end systems differ.
• Progressive harmonization: Over time, align local inspection templates, characteristic libraries, and traveler cues with the corporate standard as systems are upgraded.

Every integration should be scoped with validation and change control in mind, not just technical feasibility.

7. Control local variation instead of trying to eliminate it entirely

Total uniformity across sites is rarely realistic. Focus on what must be common and where variation is acceptable:

• Non-negotiable common elements: Triggers, required artifacts, data dictionary, approval criteria, and retention rules.
• Controlled variation: Site-specific checklists, inspection methods, or tooling as long as they map cleanly to the common characteristic set and pass the same approval gate.
• Customer-imposed variation: Some customers mandate specific portals or formats. Treat these as exceptions within a controlled framework and document them in the standard.

The key is that every FAI, from any site, can be traced, understood, and audited consistently.

8. Provide training, examples, and metrics

Standardization will not hold without active enablement and feedback:

• Standard work & training: Cross-site training on the standard workflow, including how FAIs link to travelers, routings, and engineering change.
• Reference FAIs: Share a few “gold standard” FAI packages as concrete examples of what “good” looks like.
• Metrics: Track FAI cycle time, rejections (internal and customer), rework, and recurrence of issues discovered during FAIs. Use these to drive process improvements, not just enforcement.

9. Dependencies and constraints to be explicit about

What you can standardize, and how fast, depends on:

• PLM maturity: If drawings/BoMs are not consistently managed, FAI standardization will be fragile.
• MES/QMS coverage: Plants without digital travelers or electronic approvals will rely more on scanned records and manual controls.
• Supplier and customer requirements: Flow-down obligations from primes and usage of tools like Net-Inspect will constrain how far you can standardize presentation and submission.
• Validation posture: In highly regulated programs, each change to AS9102 workflows, forms, or integrations mayrequire documented validation and evidence for auditors.

Recognizing these constraints upfront helps design a standard that is robust and realistic, not just ideal on paper.