Before starting a digital FAI pilot you should capture enough baseline data to (1) compare before/after performance credibly, (2) avoid shifting hidden work to other teams, and (3) understand constraints from your existing systems and processes. In regulated environments, this typically means at least one full quarter of data, and in some cases multiple representative programs or part families.
1. FAI volume and mix baseline
Start by understanding the scope and variability of your current FAI workload. At minimum:
- Number of FAIs per period (per month/quarter), by customer and by product line.
- Type of FAIs: full vs partial, delta FAIs, drawing revision-driven FAIs, process-change-driven FAIs.
- Part complexity indicators: key characteristics count, ballooned characteristics count, feature types (e.g., tight-tolerance machining, special processes).
- Supplier vs internal FAIs: how many packages are created internally vs received from suppliers and reviewed.
- Customer-specific formats and portals (e.g., Net-Inspect, OEM-specific Excel/PDF forms).
This gives you a realistic sample set for the pilot and avoids cherry-picking simple FAIs that will overstate digital gains.
2. Time and effort (lead time vs touch time)
To demonstrate impact credibly, distinguish between total calendar time and actual labor time. Where possible, time should be measured with real observations or time logs, not just estimates.
- FAI end-to-end lead time: from trigger (e.g., PO, ECO, first run) to customer approval or internal signoff.
- Engineering/quality prep time: drawing ballooning, characteristic listing, form population, routing/plan review.
- Inspection touch time: setup, measurement, data recording, re-measurements.
- Document and data handling time: compiling certs, C of C, special process reports, material trace, and linking them to the FAI package.
- Review and approval time: supervisor, quality, MRB, customer/DER reviews where applicable.
- Rework and repeat FAI time due to form issues, missing documentation, or measurement errors.
In brownfield environments, steps may be split across MES, ERP, PLM, QMS, shared drives, and email. Baseline measurements should reflect that fragmentation, not just the visible inspection step.
3. Quality and rework metrics specific to FAIs
Digital FAI often shifts where errors occur (e.g., fewer form errors, but new issues with data interfaces). Capture your current failure profile before the pilot:
- FAI package rejection rate (internal and customer): percentage of FAIs that are rejected or returned for correction.
- Top rejection reasons (coded, if possible):
- Missing or incorrect fields on AS9102 forms.
- Incorrect ballooning or characteristic-to-measurement mapping.
- Incomplete or mismatched certs and traceability documents.
- Out-of-tolerance features, gage/set-up issues, or sampling errors.
- Number of resubmissions per FAI on average.
- Related NCRs and MRB activity tied to FAI lots (non-conformances discovered at FAI that trigger MRB, scrap, or concessions).
- Escapes detected downstream (e.g., issues first found in receiving inspection, assembly, or by the customer after FAI approval) and whether the FAI was considered effective during root cause analysis.
Where your QMS and MES/ERP are not integrated, you may need manual correlation between FAI identifiers, lot/serials, and NCR records to build this baseline.
4. Cost and resource utilization
FAI cost is usually spread across engineering, inspection, and quality teams. Before the pilot, capture at least:
- Average labor cost per FAI (based on measured touch time by role and fully loaded rates where available).
- Overtime or premium labor attributable to FAI crunches (e.g., new product introductions, major changeovers).
- Impact on throughput: delays to production release or shipment driven by FAI completion or approval.
- Rework/scrap cost directly associated with FAI findings or late discovery of issues that FAI should have caught.
These numbers are often approximate in brownfield plants because FAIs are not always separately costed. Document assumptions explicitly so post-pilot comparisons are credible.
5. Process and workflow baseline
You will need a clear map of how FAI is performed today to understand where digital changes actually occur. Capture:
- Trigger events and ownership: who initiates FAI (planning, quality, program management) and based on what rules.
- Current workflow steps: from FAI request to closeout, including handoffs between engineering, planning, inspection, quality, and customer-facing teams.
- Approval matrix and required signoffs; how changes are documented (ECOs, deviations, concessions).
- Revisions and rework path: how corrections are made when defects or form errors are found, and how that is recorded.
- Typical bottlenecks: e.g., capacity limits in CMM, quality review queues, customer portal submission/feedback delays.
This process data is less about metrics and more about establishing a clear before/after workflow comparison and de-risking unintended process changes during the pilot.
6. Data, document, and system integration baseline
Digital FAI success is heavily dependent on how well it coexists with your current MES/ERP/PLM/QMS and document repositories. Before the pilot, document the current state:
- Source systems for FAI inputs:
- Design authority (CAD/PLM) for drawings and models.
- ERP/MES for routings, operations, BOMs, and work orders.
- QMS for AS9102 templates, NCRs, deviations, and concessions.
- LIMS or special process systems, where applicable, for certs.
- Current document flows: where drawings, certs, and forms are stored (shared drives, PLM, portals, email) and how they are linked to specific FAI records today.
- Version control and traceability practices: how revision control is enforced for drawings, specs, and FAI forms; how you verify that the FAI matches the correct drawing and spec revision.
- Existing integrations between systems (if any) used during FAI:
- Pre-population of AS9102 forms from ERP/MES data.
- Links to digital travelers/routings or inspection plans.
- Any existing Net-Inspect or OEM portal integrations.
For a pilot, you do not need to solve all integration issues up front, but you should baseline the manual work required today so that any new integration work is evaluated fairly against current reality.
7. Measurement system and inspection capability baseline
Digital FAI does not fix weak measurement systems. If you plan to use digital FAI results for quality improvement or audit evidence, capture:
- Key gage R&R / MSA results for instruments commonly used in FAI (CMM, height gages, micrometers, vision systems).
- Calibration status and intervals for critical inspection equipment.
- Known measurement pain points: features/characteristics frequently challenged by customers or internal quality.
Without this baseline, improvements or degradations in data quality during the pilot may be incorrectly attributed to the digital tool rather than to measurement system issues.
8. Compliance, audit, and evidence baseline
Since FAIs are often reviewed in AS9100/AS9102-related audits, capture how audit trails are provided today:
- Where FAI records live (paper files, network drives, QMS, customer portals) and how they are searched and retrieved.
- Average effort to compile FAI-related audit evidence for a sample of past audits, if you track this.
- History of FAI-related findings from internal audits, customer audits, or regulatory audits.
This allows you to assess whether a digital FAI pilot improves evidence accessibility or just relocates documentation effort.
9. Practical considerations and constraints in brownfield environments
In mixed-system, brownfield environments, you may not be able to collect all of the above with high precision before the pilot. Focus on:
- A representative sample of FAIs across complexity levels and customers.
- Observed time studies for a small but realistic set of current FAIs.
- Clear mapping of where data and documents actually come from today, even if that flow is informal.
- Documented assumptions and data gaps so later comparisons are transparent during internal reviews or audits.
A full replacement of existing FAI workflows or QMS/MES elements is rarely feasible in a first pilot due to validation burden, traceability requirements, and downtime constraints. Baseline data should therefore be defined in a way that supports coexistence: comparing a digital FAI slice against the existing, validated process without committing to immediate full-scale replacement.
