You are on page 1of 101

Zero Defect Plan™

UTC Aerospace Systems' Zero Defect Plan

5/8/2018 NOT FOR DISTRIBUTION OUTSIDE UTC AEROSPACE SYSTEMS WITHOUT PRIOR
EXECUTIVE APPROVAL
Revision 2.01

THIS DOCUMENT IS THE PROPERTY OF UTC AEROSPACE SYSTEMS. YOU MAY NOT POSSESS, USE, COPY OR DISCLOSE
THIS DOCUMENT OR ANY INFORMATION IN IT, FOR ANY PURPOSE, INCLUDING WITHOUT LIMITATION, TO DESIGN,
MANUFACTURE OR REPAIR PARTS, OR OBTAIN ANY GOVERNMENT APPROVAL TO DO SO, WITHOUT UTC AEROSPACE
SYSTEMS’S EXPRESS WRITTEN PERMISSION. NEITHER RECEIPT NOR POSSESSION OF THIS DOCUMENT ALONE, FROM
ANY SOURCE, CONSTITUTES SUCH PERMISSION. POSSESSION, USE, COPYING OR DISCLOSURE BY ANYONE WITHOUT
UTC AEROSPACE SYSTEMS’S EXPRESS WRITTEN PERMISSION IS NOT AUTHORIZED AND MAY RESULT IN CRIMINAL
AND/OR CIVIL LIABILITY.

This document does not contain any export controlled technical data (xClass CLS08231348)

© UTC Aerospace Systems 2018. All Rights Reserved.


Disclaimer
Supplier’s or Customer’s full or partial access to the document or information that fol-
lows shall constitute acceptance of the nondisclosure requirements of UTC Aerospace
Systems legal entities. Any acknowledgements that add to, vary from or conflict with
those terms in any way are hereby rejected. If Supplier or Customer does not agree or
has any objection to the terms below, Supplier or Customer shall not access the docu-
mentation contained therein.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page III


This document does not contain any export controlled technical data
IV UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Content
List of Figures ........................................................................................................................ VII
List of Tables ....................................................................................................................... VIII
Glossary .................................................................................................................................... IX
Executive Summary .................................................................................................................. 1
1 Zero Defect: Status, Imperative, and Path Forward .................................................. 3
2 Required Business Unit Attention and Investments ................................................ 5
2.1 Genesis: experience with key aerospace customer ........................................................... 5
2.2 Stakeholders: roles and responsibilities.............................................................................. 5
3 Methodology Overview .................................................................................................. 7
3.1 What it is ................................................................................................................................. 7
3.2 Terminology ........................................................................................................................... 9
3.3 Lessons learned .................................................................................................................... 10
3.4 ZDP process flowchart ........................................................................................................ 12
3.5 ZDP execution checklist ...................................................................................................... 12
3.6 ZDP for suppliers................................................................................................................. 12
4 Escape Data Analysis .................................................................................................... 12
4.1 What it is ............................................................................................................................... 12
4.2 How it is done ...................................................................................................................... 12
4.3 Examples ............................................................................................................................... 14
4.4 Process risk identification required steps ......................................................................... 15
4.4.1 Manufacturing process review ...................................................................................... 15
4.4.2 PFMEA update................................................................................................................. 16
4.4.3 Statistical FAIs.................................................................................................................. 17
5 Define Quality Control Actions .................................................................................. 18
5.1 What it is ............................................................................................................................... 18
5.1.1 Questions to ask ............................................................................................................... 18
5.2 How it is done ...................................................................................................................... 19
5.2.1 Pre-work ........................................................................................................................... 19
5.2.2 Data review ...................................................................................................................... 21
5.3 Best practices/lessons learned ............................................................................................ 22
5.4 Examples ............................................................................................................................... 23
6 Expand Actions to Enterprise Level ........................................................................... 25
6.1 What it is ............................................................................................................................... 25
6.2 How it is done ...................................................................................................................... 25
6.3 Best Practices as a requirement .......................................................................................... 26

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page V


This document does not contain any export controlled technical data
7 Confirm Actions through NARs ................................................................................. 26
7.1 What it is ............................................................................................................................... 26
7.1.1 Questions to ask ............................................................................................................... 26
7.2 How it is done ...................................................................................................................... 27
7.2.1 Required functional participants ................................................................................... 27
7.2.2 Best practices/lessons learned ........................................................................................ 27
8 Implement and Track Effectiveness........................................................................... 28
8.1 Key process steps ................................................................................................................. 28
9 Implement Process Control and UPPAP ................................................................... 30
9.1 How it is done ...................................................................................................................... 30
9.1.1 Mistake-proofing ............................................................................................................. 30
9.1.2 Process control and certification.................................................................................... 31
9.1.3 UPPAP .............................................................................................................................. 32
9.2 Best practices/lessons learned ............................................................................................ 34
9.3 Example ................................................................................................................................. 34
10 Driving ZDP Execution ................................................................................................ 35
10.1 Planning and execution tracking ....................................................................................... 35
10.2 Leading indicator tracking ................................................................................................. 35
10.3 Audits .................................................................................................................................... 37
11 ZDP for New Products .................................................................................................. 38
11.1 APQP ..................................................................................................................................... 38
11.2 UTAS product introduction process ................................................................................. 40
12 Deploying ZDP Methodology to Supply Base ........................................................ 41
13 Summary.......................................................................................................................... 42
13.1 Recommendations ............................................................................................................... 42
A. ZDP Common Quality Control Actions .................................................................... 45
B. ZDP Execution Checklist .............................................................................................. 64
C. Manufacturing Process Review for Zero Defect Plan Guidelines ....................... 66
D. Process and Failure Mode Analysis ........................................................................... 82
E. RPN Reduction Calculation ......................................................................................... 86
F. UTC Aerospace Systems Quality Courses ................................................................ 88
G. Authors and Contact Information .............................................................................. 89

VI UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
List of Figures
Figure 1: Customer escapes and corresponding defective ppm ......................................... 3
Figure 2: Customer scorecard .................................................................................................. 3
Figure 3: Why ZDP? .................................................................................................................. 4
Figure 4: ZDP methodology overview ................................................................................... 9
Figure 5: ZDP process flowchart ........................................................................................... 11
Figure 6: Escape trend chart ................................................................................................... 14
Figure 7: Escapes by LRU ....................................................................................................... 14
Figure 8: Escapes by defect ..................................................................................................... 15
Figure 9: Escape review form ................................................................................................. 20
Figure 10: Tracking template.................................................................................................. 21
Figure 11: High level tracker (“Blue Table”) ........................................................................ 28
Figure 12: Effectiveness tracking ........................................................................................... 29
Figure 13: Escape/ship date chart .......................................................................................... 30
Figure 14: 19 Elements of UPPAP ......................................................................................... 32
Figure 15: UPPAP Process ...................................................................................................... 33
Figure 16: Pin length process capability ............................................................................... 34
Figure 17: ZDP planning and execution tracker ................................................................. 35
Figure 18: ZDP PRO Quality Control requirement implementation form (excerpt) ..... 38
Figure 19: APQP phases .......................................................................................................... 39
Figure 20: UPI-APQP alignment............................................................................................ 41
Figure 21: Example ops. sheet mark-up ............................................................................... 71
Figure 22: PFMEA steps overview ........................................................................................ 83
Figure 23: PFMEA branching logic ....................................................................................... 85
Figure 24: Pooled average RPN calculation ......................................................................... 86

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page VII


This document does not contain any export controlled technical data
List of Tables
Table 1: ZDP roles & responsibilities ...................................................................................... 5
Table 2: Statistical FAI summary ........................................................................................... 17
Table 3: Sample analyses of escapes...................................................................................... 24
Table 4: ZDP leading indicators............................................................................................. 36
Table 5: ZDP and APQP commonalities ............................................................................... 40
Table 6: MPR checklist ............................................................................................................ 80
Table 7: ZDP-relevant courses ............................................................................................... 88

VIII UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Glossary
ACE Achieving Competitive Excellence, UTC’s operating system
ACE Bronze An ACE certification level awarded to recognize a site that conducts ad-
vanced training, clearly applies ACE tools to achieve improvements in selected pro-
cesses, has substantial employee involvement, and where leadership is significantly
involved in using ACE as the operating system
ACE Silver An ACE certification level awarded to recognize a site that uses ACE to
create a step-change to increase customer satisfaction and business results (sus-
tained for six months), demonstrates major improvements in selected processes, has
improvement activities underway on all key processes, and where employees are
empowered with a culture of continuous improvement
ACE Gold The highest level of performance recognition within ACE, given to a site
that uses ACE to create Best-in-Class customer satisfaction and business results
(sustained for 12 months), engages all levels of employees in active daily use of
ACE tools, and demonstrates successes through superior discipline in using the
ACE operating system. A Gold organization focuses on its customers by optimizing
its value streams (involving all suppliers, partners, and customers) to integrate and
coordinate all processes from end to end
APQP Advanced Product Quality Planning, a common product and control plan
guideline to design quality into products
Containment action Verified action that immediately stops the escape from reaching
the customer. Containment actions are used temporarily until verified corrective ac-
tions are implemented
Corrective action permanently eliminates the root cause of a problem
Cpk Process capability index A short-term measure of process potential that assumes a
process is in a state of statistical control, normally distributed and using an esti-
mate of the standard deviation based on a control chart with appropriately con-
structed rational subgrouping.
DCERI Defect Category Escape Reduction Initiative
DFMEA Design Failure Mode and Effects Analysis
EC Engineering Change
ECD Estimated Completion Date
FAI First Article Inspection
FNF Fault Not Found

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page IX


This document does not contain any export controlled technical data
Known-known Future escapes with known root causes affecting known parts
Known-unknown Future escapes with known root causes but with unknowns about
which parts may be affected
LRU Line Replaceable Unit, a modular item that can be removed and replaced at the
field level
MP Manufacturing Process
MPR Manufacturing Process Review
NAR Non Advocate Review
NFF No Fault Found
OEM Original Equipment Manufacturer
PFMEA Process Failure Mode and Effects Analysis
PPAP Production Part Approval Process (see UPPAP)
Ppk Process performance index A measure of process performance that uses an ordi-
nary estimate of the standard deviation based on available data
PPM (parts per million) Number of defective parts for one million parts
QCPC Quality Clinic Process Charts, an ACE data analysis tool used to continuously
collect, analyze, and reduce turnbacks
QMS Quality Management System
Quality Control Action A containment or corrective action taken to prevent further
escapes from getting to the customer
RAIL Rolling Action Item List. A to-do list for a project with clearly identified owners,
deliverables, and completion dates
REI Robust Electronics Initiative
RPN Risk Priority Number, a quantitative assessment of a risk as part of a PFMEA or
DFMEA
RRCA Relentless Root Cause Analysis, the rapid, persistent pursuit of the fundamen-
tal breakdown or failure of an identified process
SBU Strategic Business Unit
SME Subject Matter Expert
SPC Statistical Process Control
SRR Scrap, Rework, and Repair

X UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Turnback Anything that impedes the flow of material, service or information along its
intended path
Unknown-unknown Future escapes with unknown root causes and with unknowns
about which parts may be affected when (“We do not know what we do not
know”).
UPPAP UTC Production Parts Approval Process, the protocol used to ensure that all
UTC engineering and quality requirements are understood and fulfilled and that
manufacturing processes have been proven to consistently meet these requirements
at the intended production rate by integrating upfront quality planning
UTAS UTC Aerospace Systems
WIP Work in Progress
ZDP™ Zero Defect Plan™

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page XI


This document does not contain any export controlled technical data
XII UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Executive Summary
Escapes are unacceptable. We deliver parts that are critical to the safe operation of the
aircraft in which they are installed. Whether it be a family flying on a commercial airlin-
er over the Atlantic or a fighter pilot on a combat mission, our end customers count on
us to deliver systems that work all the time, every time. Given the complexity of the
parts we make, this is not a trivial task, and demands nothing less than our complete
diligence. Quality escapes directly and negatively impact our business performance
through on-time delivery problems; Scrap, Rework, and Repair; and excess inventory.
UTC Aerospace Systems (UTAS) wants to have the best quality signature in the aero-
space industry to differentiate itself from its competitors.
To accomplish this, we need to change our mindset from one accepting of 2,000 ppm
performance to one where we are infuriated by every customer escape. Some may say
that achieving zero defects is impossible, especially in our high-complexity, high-mix,
low-volume business. In reality, less than 100 ppm is within our reach if we change our
mindset and implement a zero-defect strategy. The methodology outlined in this book
leverages a company-wide understanding of past detection failures to quickly prevent
defects from becoming customer escapes, while driving data-driven process capability
improvements to prevent defects. The strategy was first developed and implemented
for UTAS products shipped to a key aerospace customer; initial results show the defec-
tive rate dropped from 20,000 ppm to less than 500 ppm within a year. This book pre-
sents the six-step methodology and necessary tools to a) prevent escapes and b) elimi-
nate the creation of defects. The steps are
1. Analyze escape data. Past escapes are reviewed to identify the escape events to
be investigated. Statistical First Article Inspections, Manufacturing Process Re-
views, and Process Failure Mode and Effects Analyses are executed and updated
to uncover gaps and risks in processes.
2. Define quality control actions. Investigations elucidate how the customer found
the escape when we did not; why, systemically, our detection systems did not
find the escape; and what systemic quality control actions will be taken to detect
this type of failure. UTC Aerospace Systems Quality organization maintains a list
of quality control actions to prevent the most common types of escapes. This list
is reviewed to include applicable quality control actions to the plan.
3. Expand actions to enterprise level. Quality control actions are expanded to all
applicable parts within the site, the Strategic Business Unit, and the Enterprise.
4. Confirm actions through Non Advocate Review (NARs). The NAR evaluates
quality control actions to answer the question: “Will the defined quality control
actions eliminate future escapes with similar failure effects (regardless of root
cause)?”

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 1


This document does not contain any export controlled technical data
5. Implement and track effectiveness. Data collection and review ensure that qual-
ity control actions are executed; containment is effective; and that needed process
improvements are identified, implemented, and effective. Turnback data identi-
fies existing process deficiencies where process capability does not match re-
quirements. To ensure effectiveness of the action items, the level of turnbacks
must be consistent with the current quality signature.
6. Implement process control and Production Parts Approval Process (PPAP).
Process control is a preventive measure to avoid making the defect in the first
place and therefore prevent escapes. Process control and certification for defi-
cient processes to match process capability with requirements eliminate defects
produced during manufacturing, in turn preventing escapes without depending
on “tail-gate” inspections. Once the process is certified, inspection requirements
are relaxed using a statistical approach. UTC Production Parts Approval Process
is the part-centric, proactive initiative to ensure that UTC Aerospace Systems’
engineering and quality requirements are understood and fulfilled and that up-
front quality planning has been integrated into manufacturing processes to con-
sistently meet these requirements at the intended production rate.
Each step of the Zero Defect Plan (ZDP™) methodology leverages existing ACE tools to
prevent product defect from reaching and impacting our customers and improve our
processes to prevent these defects in the first place.
The key recommendations in this book are
 Implement the ZDP today to prevent escapes;
 Include all steps in the ZDP, including process control;
 Monitor progress;
 Share any new widely applicable quality control actions to expand across UTC
Aerospace Systems sites; and
 Expand ZDP to UTC Aerospace Systems suppliers.
Finally, ZDP is evolving to include specific actions and processes early in the design of
new products. Courses and training material have been created to accelerate the de-
ployment of ZDP within UTC Aerospace Systems and its suppliers.

2 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
1 Zero Defect: Status, Imperative, and Path Forward
UTC Aerospace Systems’ quality performance has steadily improved over the last 10
years, due to the implementation of focused Achieving Competitive Excellence (ACE)
tools such as RRCA (Relentless Root Cause Analysis), mistake-proofing, quality clinics,
process certification, and Quality Clinic Process Charts (QCPC); however, our aggregate
performance remains at an unacceptable level relative to continually increasing custom-
er and industry expectations. Although these process-oriented tools have historically
yielded a 20-30% year-over-year improvement in escape performance to our external
customers, our escape and ppm rates are still greater than zero (figure 1 shows UTC
Aerospace Systems’ aggregate customer escape and ppm rates before ZDP).
Customer Escapes Customer PPM
(Monthly avg.) (6-month rolling avg.)

2013 2014 2015 2013 2014 2015

Figure 1: Customer escapes and corresponding defective ppm

Initial evaluation of our performance might suggest that our quality improvement
strategy is adequate until we consider a few factors. First, our customer escape event
rate of 200 per month consistently drives greater than 40% of our customer scorecards
to red or yellow (figure 2).

Overall BU 1 BU 2 BU 3 BU 4

Rolling Rolling Rolling Rolling Rolling Rolling


Customer Month Month Month Month Month
Avg Avg Avg Avg Avg Avg
PRODUCTION
Customer A 0.26% 0.34%
Customer B 99.48% 99.65%
Customer C 100.00% 92.89%
Customer D
Customer E 0.57%
Customer F 1116 210
Customer G
Customer H 93
Customer I 98.69
Customer J
Customer K
Customer L
Customer M
Customer N

Figure 2: Customer scorecard

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 3


This document does not contain any export controlled technical data
Second, our aggregate ppm does not represent the quality level of our OEM customers’
experience, as the defect rate is significantly offset by high-volume, low-complexity
spares’ shipments. Removing these spares from the equation reveals an OEM ppm
higher than the world-class performance our customers expect of the aerospace indus-
try.
Our traditional quality strategy focused primarily on driving robust RRCA and mis-
take-proofing for all escape issues, coupled with proactive process improvements prior-
itized by defect category escape trend analysis. While this methodology is effective and
has driven consistent improvement, it falls short in both magnitude and speed-to-
results. Our recently introduced UTC Production Parts Approval Process (UPPAP)
methodology is an extremely effective tool to establish process capability and prevent
escapes on new programs, work transitions, and significant engineering changes, but is
difficult and costly to retroactively implement across our large number of legacy pro-
grams without an effective prioritization methodology. To truly become a world-class
company in terms of quality performance, we must build on and supplement these
methodologies with a more rigorous and structured approach: the ZDP methodology.
The automotive industry achieved low defect rates by investing in quality and driving
full process certification and UPPAP for all parts over decades. ZDP reduces the re-
sources and investment needed to achieve defect rates lower than 100 ppm within
months by:
1. Implementing rigorous quality control to
a. immediately prevent escapes to customers and
b. identify process deficiencies
2. Executing PPAP and process certification to eliminate process deficiencies for all
parts.
The difference in approaches to get to Six Sigma defect rates between the automotive
industry and UTC Aerospace Systems is summarized in figure 3.

Automotive ProCert/PPAP 6σ
100% parts <10 ppm

ZDP
Quality control &
Path to Gold/ 4σ 5σ
Aerospace ProCert/PPAP of
ProCert/PPAP
(UTAS) ~5000 ppm 100% of incapable <250 ppm
~5% parts
processes
100% parts

Figure 3: Why ZDP?

4 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
2 Required Business Unit Attention and Investments
2.1 Genesis: experience with key aerospace customer
The ZDP methodology was developed in response to consistently inadequate perfor-
mance from five UTC Aerospace Systems sites on a key customer’s quality scorecards.
The customer’s senior leadership communicated its frustration with UTC Aerospace
Systems’ inability to drive improvement at these sites and threatened to suspend new
program opportunities until we could demonstrate improvement. They also cited one of
UTAS business units’ dramatic scorecard turnaround after implementing an effective
ring-fence inspection strategy and questioned why other underperforming sites could
not achieve similar results.
The ZDP was designed to drive rapid (months rather than years) improvements in
quality escape performance by supplementing existing strategies with a rigorous, data-
driven quality control/containment and best practice read-across methodology. This
methodology would detect and prevent customer escapes until more sustainable (albeit
slower) process improvements could take hold. Even aggressively implemented process
improvement strategies require months to years to yield concrete results the customer
can feel; however, the ZDP added a new dimension through upfront quality control ac-
tions that prevented defects from becoming escapes. The customer enthusiastically en-
dorsed this strategy thanks to promising initial results.

2.2 Stakeholders: roles and responsibilities


To successfully reduce customer escapes, each team member must have specific roles
and responsibilities. The key stakeholders in the Zero Defect project are summarized in
table 1.
Table 1: ZDP roles & responsibilities

Role Responsibility

Site Leader / General  Understand the process of ZDP methodology and the impact
Manager on staffing levels, EBIT, and customer satisfaction
 Provide oversight at regular intervals to all ongoing ZDP
projects
 Provide interdisciplinary resources for process improvements

Product Line Manager  Provide leadership at regular intervals to all ongoing ZDP
projects
 Identify key programs/projects for investigation
 Provide key data that will allow the project with the most po-
tential to be chosen

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 5


This document does not contain any export controlled technical data
Quality Engineering  Provide site ownership of ZDP methodology
Manager  Execute ZDP methodology effectively and efficiently
 Coordinate sites’ ZDP efforts and reporting to SBU and the
Quality organization

Supplier Quality  Understand ZDP methodology


Manager  Execute ZDP methodology effectively and efficiently
 Review and monitor ZDP effectiveness at suppliers’

Manufacturing  Understand ZDP methodology


Manager  Provide ownership of manufacturing processes
 Execute ZDP methodology effectively and efficiently

Design Engineering  Understand the process of ZDP methodology and supporting


Manager expertise and data that may be required for execution
 Provide Subject Matter Experts (SME) who can help with Re-
lentless Root Cause Analysis (RCCA) and containment
screening
 Extract variation issues into robust design issues for future
development programs
 Incorporate design lessons learned into standard work for fu-
ture development work

Test Engineer  Understand the process of ZDP methodology and its effect
on the test environment
 Incorporate test coverage lessons learned into standard work
for test plans on future development work

Central Quality  Provide a methodology that can be executed within UTC


Organization Aerospace Systems for developing ZDPs
 Own ZDP deployment to achieve goals
 Provide recommended suppliers common tools such as au-
tomated part marking, automated optical inspection, shadow
boxing, etc.
 Train, maintain, and expand the number of experts in the
techniques and processes of ZDP methodology
 Provide expertise to any ZDP program that cannot execute a
ZDP or specific escape investigations
 Provide leadership at regular intervals to all ongoing ZDP
projects
 Collect, refine, and update the ZDP methodology using les-
sons learned
 Work with Design and Test Engineering to expand the effort
into a robust design initiative to eliminate quality issues and
test coverage gaps in the design phase.

6 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
 Coordinate activity, as needed, when multiple product lines,
sites, or customers are involved in a ZDP, which may in-
clude:
o Developing a common electronic location to keep all data
accessible to all stakeholders
o Developing and managing a common schedule
o Coordinating NAR attendance
o Maintaining a common master template and format
 Maintain the common list of enterprise-wide best practices
sites are required to implement as they execute the zero de-
fect methodology to existing or new development programs

3 Methodology Overview
3.1 What it is
ZDP is a data-driven methodology to first achieve zero escapes and then drive to zero
defects. The six steps of ZDP (figure 4) are
1. Analyze escape data. Review past escapes (typically three years) to identify the
escape events to be investigated (based on trends, Pareto charts, customer im-
pact). Review each escape event individually to capture how it was contained,
root cause(s), corrective action(s), and detection breakdown. These data form the
foundation of the ZDP methodology. Statistical First Article Inspections (FAI)
and Manufacturing Process Reviews (MPR) are conducted to uncover gaps in
these processes and Process Failure Mode and Effects Analyses (PFMEA) are re-
viewed and updated.
2. Define quality control actions. Based on the escape data step, identify
a. How the customer found the escape when we did not. If the escape was
self-identified, how did we eventually find the escape when we missed it
originally?
b. Why, systemically, our detection systems did not find the escape;
c. What systemic actions will be taken to detect this type of failure effect in
the future;
d. How many parts this action apply to (read-across);
e. What effectiveness measure(s) will be used to monitor the detection sys-
tem and provide information on long-term process improvement; and
f. Which of the 10 common action categories (Appendix A; identified by re-
viewing all previous zero defect reviews at other sites, businesses, and
product lines) are applicable, as appropriate, across all parts.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 7


This document does not contain any export controlled technical data
Implementing the defined quality control actions and effectiveness measures is
the key to ZDP methodology. The quality control actions allow us to achieve zero
escapes, while the effectiveness measures allow us to identify the process im-
provements needed to achieve zero defects. These actions are further expanded
from one part to all similar parts within the site.
3. Expand actions to enterprise level. Review the quality control actions (step 2)
and apply those actions, as appropriate, across all parts at all sites. This results in
an implementation plan that includes ownership, completion status, and comple-
tion date on a part-by-part/action-by-action basis.
4. Confirm actions through NARs. A NAR provides an in-depth assessment of a
critical issue using independent SMEs. As part of the ZDP, the NAR evaluates
the quality control actions to answer the question: “Will the defined quality con-
trol actions eliminate future escapes with similar failure effects (regardless of
root cause)?”
a. Apply any new quality control actions identified during the NAR to all
applicable parts.
5. Implement and track effectiveness. Implementing the plan includes regular
(recommended weekly) tracking of
a. % commitment to identified actions,
b. % actions complete,
c. action estimated completion dates,
d. number of actions performed, and
e. number of defects and/or turnbacks detected.
These data are reviewed to ensure that quality control actions are on plan, con-
tainment is effective, and needed process improvements are identified and effec-
tive.
6. Implement process control and UPPAP. Process control changes are implement-
ed based both on the root cause of escape events and additional risk conditions
the ZDP methodology containment actions identify through turnback analysis.
The effectiveness of process control actions is validated by containment actions
before the containment actions are reduced or retired. Process control actions in-
clude, but are not limited to, statistical process control, process automation, and
mistake-proof level 1. UPPAP ensures process control and capability for any
product and/or process changes (e.g. engineering/process changes and work
transfers). UPPAP actions drive the identification and mitigation of risk early in
the design and process development phases for product introductions to ensure
continuous design and process improvement. UPPAP also ensures that customer
requirements and variation management goals are met, which will result in de-
fect-free products delivered to our customers on time, every time.

8 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Escape Data Analysis Define Quality Control Expand Actions to
(past 3 years) Actions Enterprise Level
Site escape events

2012 2013 2014 2015 Reject

Flange hole Keys added to test rig


inspection
Read-across fixture
Analyze escapes by part number and process Customer interface 100% verification of Implement quality control best practices
Manufacturing process reviews/PFMEA/ fittings reversed interface features to based on escapes from all facilities & PFMEA
statistical FAI all customer
products
CRM data

Confirm Actions Through Implement & Track Implement Process


NARs Effectiveness Control & UPPAP
Actions
25 LSL Urethane Conformal Coat Thickness USL
Total Total
Action Category S1 S2 S3 S4 S5 Total ECD
Inspection Turnbacks
Urethane Conformal Coat Thickness
100% Customer 20 (Vergennes)
40 44 6 3 9 102 Complete 2785 24
Interface Verification
Automated Inspection 3 132 0 23 15 173 10/31/2016 4212 13 15
Test Coverage 12 74 0 3 20 109 6/30/2016 2156 14

Process Automation 28 44 11 3 5 91 10/31/2016 925 0 10


Internal Inspection 21 112 9 27 34 203 5/20/2016 5452 798

Supplier Over- 5
4 4 44 5 17 74 10/28/2016 3415 41
Inspection
Change control 1 1 11 1 1 15 Complete 3718 0
CCpk == 2.11
2.11
0
pk
Site Specific 41 240 26 26 21 354 10/31/2016 7460 155

Total Actions 150 651 107 91 122 1121 30123 1045 2.4 3.6 4.8 6.0 7.2 8.4 9.6

Ensure defect detection Measure turnbacks and near-misses for all Drive process capability with UPPAP
quality control categories Replace quality control actions with verified
Audit action implementation process improvements

Figure 4: ZDP methodology overview

3.2 Terminology
As part of the zero defect plan, three terms describe the types of escapes:
 Known-knowns: future escapes with known root causes affecting known parts.
For example, an electronic board fails because of cracked solder joints (the root
cause) at known solder joints.
 Known-unknowns: future escapes with known root causes but with unknowns
about which parts may be affected. For example, an electronic board fails be-
cause of cracked solder joints but what specific joints are affected is unknown as
there can be thousands of solder joints on the electronic board.
 Unknown-unknowns: future escapes with unknown root causes and with un-
knowns about which parts may be affected when. For example, an electronic
board fails for unknown root causes and with unknowns regarding what parts
are affected.
Specific containment actions are taken to address each type of escape and are deter-
mined by the nature of the root causes:
 Known-knowns’ containment actions are based on the direct cause of the defect
or of the detection failure. These actions prevent recurrence of the specific escape
but not of similar escapes with differing root causes or part numbers. These ac-

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 9


This document does not contain any export controlled technical data
tions can immediately prevent repeat escapes and should be in place as soon as
possible.
 Known-unknowns’ containment actions are based on the systemic type of the de-
fect. These actions prevent recurrence of the specific escape and of similar es-
capes with similar root causes or part numbers. These actions begin the process
of preventing similar escapes from reaching the customer based on our under-
standing of systemic root cause of the escape and systemic corrective actions.
 Unknown-unknowns are our blind spots. These are escapes with systemic causes
yet to manifest in our escape data analysis and should be categorized as “new
learnings.” Once these unknown-unknowns occur, they become known-knowns
and should be read across as known-unknowns in the ZDP process. The key to
their prevention is
- the implantation of systemic containment actions based on previous es-
capes and quality control best practices; and
- a robust PFMEA and manufacturing process review (MPR) methodology.
The intent is to have actions that can detect the defective condition, regardless of
root cause, and therefore prevent delivery of a defective product to our custom-
ers.

3.3 Lessons learned


Developing the ZDP methodology and, in particular, identifying common best practices
and read-across opportunities initially required that actions be confirmed through NAR
(step 4) before actions were expanded to the Enterprise levels (step 3). The list of com-
mon quality control actions is now mature enough to execute the ZDP and expand ac-
tions to enterprise levels before the NAR (figure 4). Newly identified common best prac-
tices to expand to enterprise level get added to the existing list once approved by the
NAR and the Quality organization SMEs and Fellows.

10 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Escape Data Analysis

Additional Prioritize Statistical


Conduct
Escape Data learnings from escape with FAI to
Review Freeze Immediate MPRs and
(Up to 3 years other highest number identify
Data processes screening update
prior) customers and of events / part incapable
PFMEAs
internal issues numbers processes

Define Quality Control Actions

Review of ZDP Identify quality


common quality control actions for
Ask 6 ZDP Questions
control actions and immediate detection
(each escape)
applicability to each & containment (zero
escape escape)

ZDP common
quality control
actions
Expand to Enterprise Level

Recommend new quality


Read across for Read across for control actions for ZDP
all site/product all UTAS parts inclusion in list of ZDP Implementation
line parts (SBU/Enterprise) common quality control Draft
actions

Non Advocate Review

Inclusion of new ZDP


common ZDP Complete NAR implementation
quality control actions plan

Implement & Track Effectiveness

Summarize status of Understand what


Implement all Measure turnbacks New escapes
actions, inspections, was missed and
Quality Control Determine actions (post ZDP
turnbacks drive new quality
actions effectiveness implementation)
( “Blue table”) control actions

Implement Process Control/UPPAP

Identify drivers Monitor


Analyze process Improve key and
of variation & processes/
Mistake proofing capability incapable
corrective Statistical
(include MSA) processes
actions Process Control

Figure 5: ZDP process flowchart

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 11


This document does not contain any export controlled technical data
3.4 ZDP process flowchart
Each of the six steps of the ZDP methodology has multiple sub-steps. The ZDP process
flowchart (figure 5) captures the principal sub-steps, with details covered in Sections 4
through 9.

3.5 ZDP execution checklist


A checklist (Appendix B) will facilitate the execution of all six steps of the ZDP. The
checklist, also used as part of ZDP audits, should be reviewed and updated regularly to
document progress.

3.6 ZDP for suppliers


The sections in this book are written in the context where the “customer” is UTC Aero-
space Systems customers and “we” or “our” refers to a UTC Aerospace Systems’ facili-
ty. For a supplier using this how-to book, the “customer” is UTC Aerospace Systems
and “we” or “our” is the supplier creating a ZDP (cf. Section 10). Suppliers should flow
down the ZDP to sub-tier suppliers.

4 Escape Data Analysis


4.1 What it is
The site reviews past escapes to customers, typically up to three years. This analysis
should include all escapes from the customers’ perspective, including events where the
site did not confirm the escape as their liability, but the customer continued to count it
against the site on their scorecard. Every escape indicates both a process gap and a qual-
ity control gap that need to be addressed. Pareto by Line Replaceable Unit (LRU) and
Defect Category Escape Reduction Initiative (DCERI) category may highlight known-
unknown containment opportunities.
In parallel, the site needs to perform MPR, PFMEA updates, and statistical FAI, all of
which are data rich, to identify gaps in processes and capabilities that may turn into es-
capes.

4.2 How it is done


Typically, the site quality department has a database of customer escapes, including
cases where the site has made a disclosure or a “notification of potential quality escape”
to the customer. The following information should be extracted from the database and
summarized for each escape event where the investigation is considered complete:
 Item number, which is an assigned number to help reference the case;

12 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
 Business Unit;
 UTAS Site (Ship Site);
 Customer;
 Customer Doc Number;
 Clinic number;
 Initiation Date (First Event Date);
 Program, the platform for which the part was intended (e.g., A350);
 Part number;
 Event Name, only a couple of words to describe the defect (e.g., loose bolt);
 Rejections Per Event;
 Event Date (Last Event Date);
 Direct Cause of Escape;
 Corrective Action (C/A);
 Defect category (e.g. DCERI);
 Serial number;
 Detection breakdown and explanation;
 Immediate containment: what are the known-knowns’ containment actions
(needed or in place) to prevent the escape from occurring; and
 Immediate containment Estimated Completion Date (ECD).
If information is missing, the site will research the escape to create as complete a picture
as practical depending on the complexity of the escape and impact to the business.
An escape event is defined as occurring on a single part number and with the same root
cause. The team should not lump escapes with the same symptom into one event. For
example, if an electronic controller has several functional failures due to solder issues,
they will likely be different events unless the solder issue is in the same location, on the
same piece part component, and has the same root cause. The escape review table
should include one row for each escape event.
As soon as a part is put on ZDP, with or without a history of escapes, the manufactur-
ing engineer needs to immediately implement
 Process freeze. Many escapes are the result of non-validated process changes.
Thus, as part of ZDP, manufacturing processes are “frozen”; that is, no process
changes can be made unless these changes are thoroughly validated and docu-
mented; and
 Screening for known or suspected defects. These are containment actions that can
be put in place within hours or days, such as over-inspection, additional screen-
ings, or more stringent acceptance tests.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 13


This document does not contain any export controlled technical data
4.3 Examples
Figure 6 through figure 8 present typical charts used for data analysis. Figure 6 shows a
sample trend chart for escapes to a customer, which provides an overview of number of
escapes, trends in time, and where some of these escapes occur. For this example, UTC
Aerospace Systems’ various businesses are used as categories, but categories can also be
production sites, lines, etc.

51

41 40 SBU 6
36
SBU 5
SBU 4
SBU 3
SBU 2
SBU 1

2013 2014 2015Q1 2015Q2

Figure 6: Escape trend chart

An example Pareto by LRU part number is shown in figure 7. This type of plot provides
more details in terms of which products have the most escapes.
29

2015
2014
2013
13
12
11
10 10
9
7
6 6 6
5 5
4 4 4 4
3 3 3 3 3
2 2

Figure 7: Escapes by LRU

Finally, escapes can be sorted by defects or process failures to help identify common de-
fects across products (figure 8).

14 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
4 4 4

2 2 2 2

1 1 1

Figure 8: Escapes by defect

Escape Pareto and trend analyses are useful in defining the initial scope and priority for
ZDP implementation (customer, part number, product line, etc.), but do not replace the
discrete, escape-by-escape review described.

4.4 Process risk identification required steps


ZDP must identify the process gaps and risks that could generate future escapes, and
requires using
 Manufacturing process reviews to identify risks in repeatedly producing parts
that meet all design requirements;
 PFMEA to identify and mitigate potential failure modes of the manufacturing
process; and
 Statistical FAI to provide early assessment of which features have a higher risk of
process variation.

4.4.1 Manufacturing process review


The intent of an MPR is to validate that all design requirements are producible repeat-
edly within specifications and without defects. These reviews should be conducted for
all ZDP parts with or without escape events.
Goals of an MPR are to
 Identify manufacturing process weaknesses to understand why these weakness-
es were not identified;
 Define quality control actions to mitigate risks until better processes can be put
in place to prevent escape pieces;
 Update blueprints to capture or clarify requirements, which may include defin-
ing new critical characteristics; and

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 15


This document does not contain any export controlled technical data
 Update manufacturing instructions to accurately capture design requirements
and reduce room for interpretation and process variations.
The MPR is conducted by a cross-functional team that includes Operations and Quality
from the ship site and Design Engineering. At least one person for each function should
have product knowledge. A SME, especially when dealing with more advanced and
special processes, should also participate.
During an MPR, a good practice is to physically walk down the process with the design
blueprints in hand to identify gaps or discrepancies in the processes. The blueprints
serve as the reference, not the work instructions, since these instructions may contain
errors (the work instructions are also reviewed for accuracy and areas for improve-
ments, using both the design blueprints and the processes in place). For each design fea-
ture, the review team needs to ask, and preferably witness, the production steps, if any
underlying manufacturing processes can deliver the feature within specifications every
time. Variations in processes must be considered and, when possible, data should sup-
port the assessment.
Following this review, quality control actions should be defined and implemented to
contain and prevent identified risks to produce defective parts, the manufacturing in-
structions updated to reflect lessons learned, and design specifications updated to re-
flect identified gaps (e.g. missing or inadequate requirements).
Appendix C provides further information on how to execute an MPR.

4.4.2 PFMEA update


The PFMEA is a proven industry methodology to prevent and/or mitigate potential
failure modes in the manufacturing process. As part of the MPR, or soon after, PFMEA
are reviewed in depth and updated accordingly. In particular, all escape events where
the detection breakdown indicated inadequate test coverage or inspection as the reason
the escape was not detected require special and urgent attention, as they may point to
other gaps in the PFMEA.
The PFMEA review follows the MPR to ensure
 Risk assessments are up-to-date with latest findings and escape history,
 the original probability of detection analysis is up-to-date, and
 new quality control actions are defined to address identified risks in the PFMEA.
The PFMEA is a living document that needs to be reviewed and updated regularly.
If no PFMEA exists for a ZDP part, a corrective action should be to complete a PFMEA
for each part as soon as possible.

16 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
4.4.3 Statistical FAIs
A “classical” FAI is a snapshot in time of what the manufacturing processes produce,
but does not indicate variations in these processes and, therefore, whether the processes
can produce non-defective parts repeatedly. To accelerate the detection of incapable
processes and add protective inspection for the identified incapable processes, ZDP
calls for a statistical FAI. In a statistical FAI, every quantitative feature on the design
blueprint is measured on a 25-piece sample. The process performance index (Ppk) is cal-
culated for each feature using only the data from these 25 pieces.
Any feature with a Ppk less than 1.67 is put on a 100% inspection plan for any new part
until the process is demonstrated to be capable of delivering a Ppk greater than 1.67.
Again, if a feature is found to have a Ppk less than 1.67 as part of the statistical FAI, that
feature needs to be inspected for every new part made until the processes are improved
to ensure Ppk is greater than 1.67. Ppk does not apply to categorical variables.
Statistical FAIs have been performed at multiple UTC Aerospace Systems sites and
suppliers on parts of different natures and functionalities, from simple mechanical parts
to complex assemblies. Sample statistical FAI statistics are presented in table 2. Results
show that between 20 to 30% of features have Ppk less than 1.67 at most sites. Hence, it is
statistically only a matter of time for one of these features to be out of specification.
Table 2: Statistical FAI summary

Site #PNs # dimensions # dimensions w. Ppk <1.67


A 12 278 50
B 8 126 31
C 1 8 0
D 4 844 343
E 7 7 6
E 1 20 3
G 1 8 5
H 3 140 30

The 100% inspection of features identified through the statistical FAI provides addi-
tional protection against an escape. The added inspection should incentivize the pro-
ducer to improve the manufacturing processes to reduce variation and remove the need
for 100% inspection. To uncover potential critical characteristics, best practice also
means reviewing design specifications while considering the statistical FAI results.
Specification limits may be relaxed if performance and safety of the part are not com-
promised.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 17


This document does not contain any export controlled technical data
The Process Performance Index is defined as
𝑈𝑆𝐿 − 𝑋̅ 𝑋̅ − 𝐿𝑆𝐿
𝑃𝑝𝑘 = min( , )
3𝑠 3𝑠
where 𝑋̅ and 𝑠 are the sample mean and standard deviation, and USL and LSL are the
Upper and Lower Specification Limits, respectively. Only using the 25-piece sample da-
ta is equivalent to a short-term Ppk calculation. The 1.67 threshold is to deliver 5σ per-
formance, and accounts for a possible 1.5σ shift in the feature’s mean. The 1.5σ shift ac-
counts for potential drifts in the means over time, as the 25-piece is too small a sample
to capture such drifts.
Using a Process Capability Index (Cpk) instead of a Ppk is acceptable if, and only if, all
conditions to the applicability of Cpk are met and demonstrated: normality of data dis-
tribution, under-control process, properly defined rational subgroups, etc.
If a part or site has a history of dimensional escapes then a high priority corrective ac-
tion should be to complete a statistical FAI for each part.

5 Define Quality Control Actions


5.1 What it is
Quality control actions ensure that escapes do not make it to the customer. The first fo-
cus of the ZDP is to identify systemic detection and containment actions that will pre-
vent all escapes with similar defects, regardless of root cause. Implementation of the de-
fined quality control actions and effectiveness measures (Section 8) is key to ZDP meth-
odology. Quality control actions allow us to achieve zero escapes, while effectiveness
measures allow us to define process improvements needed to achieve zero defects.

5.1.1 Questions to ask


To define the quality control actions (based on the escape data analysis in Section 4), we
need to answer these questions for each escape event:
1. How did the customer find the escape when we did not?
2. Why, systemically, did our detection systems not find the escape?
3. What systemic actions will we take to detect this type of failure effect?
4. How many parts does this action apply to?
5. What effectiveness measure(s) will we use to monitor the detection system and
provide information on long-term process improvement?
6. What are the ECDs for implementing the control actions?

18 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
These questions should be answered for each escape event individually. Although the
end goal is to apply the control plans systemically, basing the plans on the detailed re-
view of the facts and data for individual escapes is what leads to effective control plans.

5.2 How it is done

5.2.1 Pre-work
Data are collected and summarized to support data review during the NAR. The pre-
work has three main parts to help create control plans:
1. Collect summary data for each escape event to be reviewed (Section 4.2) and put
summary data into a spreadsheet (figure 9).
2. Answer the six questions outlined in Section 5.1.1 as a site and in advance of the
NAR. While answering these questions, the site team should focus on how a “de-
fective” part was allowed to escape and what containment actions we will take to
eliminate similar “defective” parts from reaching our customer.
3. Review each of the common actions outlined in Appendix A for applicability and
implementation date and by part number (or part family) for the site. These data
are used to define and implement quality control actions and serve as the basis
for execution of the NAR.
This information can be summarized in a spreadsheet (figure 9) using the ZDP template
available from UTC Aerospace Systems Quality organization.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 19


This document does not contain any export controlled technical data
UTAS Initiation Immediate

20
Direct Cause of Escape Immediate
Business Site Customer Doc Date Rej. Per Event Date Unique Detection Containment
Item Clinic # Year Program Part Event Name (All customer detail of C/A Containment
Unit (Ship Number (Event Date Event (last) Event Breakdown ECD
rejection) (Known Known)
Site) first) (MM/DD/YY)

Escape Review Template Based upon data review of past escapes events (typically 3 years) identify the escape events to be investigated (based on
trends, paretos, customer impact). The Escape Reivew Template is populated with supporting (individual, detailed) CLOSED clinics/RCCA Investigations
associated with the specific part numbers or part families contributing to customer escapes. A cross functional team working together should review
each clinic. The working team should, as a minimum, include: Design engineering, supplier management, Manufacturing engineering, operations, and
quality.

Systemic Containment Contain- Read Read


Why did the customer find it and Why, systemically, did we not Effectiveness Read Across Action
(Known Unknown) ment across Across Action Category
we didn't? have Detection in place measurement Owner
Status ECD Scope

Working together, the Cross Fucntional should define Systemic containment actions by asking the following questions:

Figure 9: Escape review form


1. How the customer found the escape when we didn’t?
2. Why systemically did our detection systems not find the escape?
3. What systemic actions will be taken to detect this type of failure effect in the future?
4. How many parts does this action apply to?
5. What effectiveness measure will be used to monitor the detection system and provide information on long term process improvement?

Attempt at least (5) and then review results with Quality Fellow to ensure appliciation of Read Across Actions is understood. Perform this
step prior to completion of all (20-30) clinic reivews.

This document does not contain any export controlled technical data
BU/Site will be required to have completed sheet for NAR.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


Customer N/A Gulfstream Gulfstream Gulfstream Gulfstream Gulfstream Gulfstream
Platform N/A G650 G650 G650 G650 G650 G650
Part Family N/A NLG MLG MLG Side Brace Actuator Uplock Uplock
Business
Unit LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville
Production
Site LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville
Ship Site
LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville LS-Oakville
Final Action Shipped Part
Reference # Action Category Escape Prevention Action Action Summary - All Control Plan Results Site Process Actions
Date Number
MLG - LH MLG- RH Uplock MLG Uplock NLG
Commit Commit Commit Commit Commit
Complete Open No Dates Total # Test/Insp # Turnbacks
Owner O/C Date LE # Test/Insp # Turnbacks Owner O/C Date LE # Test/Insp # Turnbacks Owner O/C Commit Date LE # Test/Insp # Turnbacks Owner O/C Commit Date LE # Test/Insp # Turnbacks Owner O/C Date LE # Test/Insp # Turnbacks Owner O/C Date LE # Test/Insp # Turnbacks Owner O/C Date LE # Test/Insp # Turnbacks
100% verification of customer interface
characteristics w/go no-go gauges where
Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
1a appropriate. Ensure all aircraft connections 2 24 0 26 0 0 N/A N/A N/A N/A N/A N/A N/A O N/A N/A N/A N/A O N/A N/A O N/A N/A O N/A N/A O N/A N/A O N/A N/A
R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury
100% Customer are checked with an aircraft representative
Interface unmodified interface
Verification 100% Visual inspection of Customer
interfaces at final bench Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
1b 0 26 0 26 0 0 N/A N/A N/A N/A N/A N/A N/A O 11/31/2016 11/31/2016 N/A N/A O 11/31/2016 11/31/2016 O 11/31/2016 11/31/2016 O 11/31/2016 11/31/2016 O 11/31/2016 11/31/2016 O 11/31/2016 11/31/2016
R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury

2a Implement pre-coat AOI 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
AOI application to PTH (Plated through hole)
2b 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
boards
Apply AXI to detect solder bridge under fine-
2c 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
pitch components
Automated Change from SMT to BOM-based AOI
2d Inspection 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
programming
Implement 3 dimensional AOI (e.g. laser-
2e 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
based)
Automated optical inspection (OCR/UID) for
2f part marking 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

Assess all ECs in the past three years for


3a 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
impact to ATP
Test Power Electronic units at sustained rated
3b 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
load during ESS thermal cycle
For power electronics, check and update
3c dielectric test for margin & location in the build 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
cycle (including PWBA testing)
Determine probability of detection of
Test Coverage intermittent failures during vibration and
thermal testing. For example, add additional
3d 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
vibration axes with consideration for aircraft
mounting. Consider how/when unit is
interrogated during environmental testing.
Optimize ESS testing cycles based on failure
profile. Utilize QN system and MRB
3e 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
engineering to disposition all failures (whether
or not in last 2 cycles)
Implement automated serial number
generation and automated part marking,
including duplicated serial number check.
Verify automation processes with transfer to
4a 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Process SAP R2.
Automation
Require QE sign-off for any manual override
or format correction of process automation
Implement automated torqueing (e.g. Atlas Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
4b 0 26 0 26 0 0 10/31/2016 N/A N/A N/A N/A N/A N/A O 10/31/2016 N/A N/A N/A O 10/31/2016 N/A O 10/31/2016 N/A O 10/31/2016 N/A O 10/31/2016 N/A O 10/31/2016 N/A
Copco and Pinpoint software) R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury
In-process inspections for workmanship,
5a 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
FOD/contamination, and part marking
Implement post-rework inspection & test
5b 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
(thermal & vibe) standard work
Define and implement visual overinspect
5c standards following all hand solder operations 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

Utilize work transfer process (UTAS-PRO-


0008) for all internal equipment moves. Audit
5d 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
last 5 years for equipment moves.

Electrical connector and wire clearance and


routing audit to REI Std Work, including, for
example: clearance issues due to potential
misassembly & tolerance stackups,
wire/strain relief escape opportunities, etc. Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
5e 0 15 0 15 0 0 N/A N/A N/A N/A N/A N/A N/A O N/A N/A N/A N/A O N/A N/A N/A N/A O N/A N/A N/A N/A O N/A N/A O N/A N/A N/A N/A O N/A N/A N/A N/A
Internal R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury
Inspection Define KPCs and deploy go/no-go gauges
accordingly.

Mistake Proof for control of gold boards/units

5f 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

Develop & Implement customer agreed


cosmetic standards for high risk features
5g 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

Verify best practice moisture controls are in


place for printed circuit board manufacturing
5h 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
and assembly as defined by

Risk based over inspection (e.g. double DQR, Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
6a 0 24 0 24 0 0 N/A N/A N/A N/A N/A N/A N/A O 9/31/2016 9/31/2016 N/A N/A O 9/31/2016 9/31/2016 N/A N/A O 9/31/2016 9/31/2016 N/A N/A O 9/31/2016 9/31/2016 N/A N/A O 9/31/2016 9/31/2016 N/A N/A O 9/31/2016 9/31/2016 N/A N/A
3rd party, UTAS source) R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury
UTAS review of all supplier FAIs (going
6b 27 0 0 27 0 0 4/11/2016 N/A N/A N/A N/A N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A SQA C 4/11/2016 4/11/2016 N/A N/A
forward)
6c Supplier Over- Verify all suppliers for compliance to Buy 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Inspection American Act
6d Extend all to drop ship suppliers 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Risk-based component screening:
Upscreening based upon component failure
6e 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
history (collaborate with REI COTS initiative)

Suspend use of controlled release processes


7a 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
for all customer products
Change control Require Level 3 PPAP or higher for all F-35
7b work transfers 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

The correct version of software loaded will be


verified following all other production and test
software modifications including test software
loads, fault memory clearing, final production
8a load. Verification of the software will be based 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
on validation of the proper check code (CRC,
Software
Checksum, or equivalent) is both stored
Version/Load
correctly and passes internal built in test.
Control
If the software version is transmitted from the
unit for display and/or check by any other
8b hardware then this transmission will be 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
verified once final software is loaded by
reading and displaying the information
transmitted
Eliminate metal on metal contact during
9a kitting, assembly, test, and transportation of 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Handling/Packag hardware.
ing/Shipping Risk based review packing instructions for
9b shipping for best practices in eliminating 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
shipping damage
Review items with a high rate of FNF and
Customer
10a customer damaged with customer to identify 0 6 0 6 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Collaboration
actions to eliminate both

During FAI material properties will require


M&PT review when material requirement does G. Hunjan G. Hunjan G. Hunjan G. Hunjan G. Hunjan G. Hunjan
S1 0 26 0 26 0 0 5/30/2016 N/A N/A N/A N/A N/A N/A O 5/30/2016 5/30/2016 N/A N/A O 5/30/2016 5/30/2016 N/A N/A O 5/30/2016 5/30/2016 N/A N/A O 5/30/2016 5/30/2016 N/A N/A O 5/30/2016 5/30/2016 N/A N/A O 5/30/2016 5/30/2016 N/A N/A
not match the material certification directly R. Maduta R. Maduta R. Maduta R. Maduta R. Maduta R. Maduta
(LGPS 8000 designated parts only)
Verification of EDF expansion via a movement
S2 check following installation after removal of the 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
clamp up nut.
Investigate a non-destructive test to verify
S3 0 2 0 2 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
base material around chrome edge
Off-Load part must be shipped from Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang Sh. Huang
S4 0 27 0 27 0 0 10/31/2016 N/A N/A N/A N/A N/A N/A O 10/31/2016 10/31/2016 N/A N/A O 10/31/2016 10/31/2016 N/A N/A O 10/31/2016 10/31/2016 N/A N/A O 10/31/2016 10/31/2016 N/A N/A O 10/31/2016 10/31/2016 N/A N/A O 10/31/2016 10/31/2016 N/A N/A
originating quality system R. Jury R. Jury R. Jury R. Jury R. Jury R. Jury

S5 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

S6 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

S7 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Site Specific
Containment

S8 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

S9 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

S10 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S11 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S12 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S13 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S14 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S15 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S16 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S17 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S18 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S19 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
S20 0 0 0 0 0 0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
TOTAL 29 176 0 205 0 0 10/31/2016 N/A 0 1/0/1900 1/0/1900 0 0 N/A 8 10/31/2016 10/31/2016 0 0 N/A 8 10/31/2016 10/31/2016 0 0 N/A 8 10/31/2016 10/31/2016 0 0 N/A 8 10/31/2016 10/31/2016 0 0 N/A 8 10/31/2016 10/31/2016 0 0 N/A 8 10/31/2016 10/31/2016 0 0

Figure 10: Tracking template

5.2.2 Data review


The gathered information is reviewed by a cross-functional team that includes Opera-
tions and Quality from the ship site and Design Engineering for the product being re-
viewed. In addition, including Program Quality, Manufacturing Engineering, Test En-
gineering, and Supply Chain representation may be necessary to develop a clear under-
standing of the escape event. The questions to be answered during this review are out-
lined in Section 5.1.1 and captured in the escape review form (figure 9).
The process to answer each question is to:
1. Review findings from completed RRCA activities. This review should include all
that was documented as part of the RRCA and through discussions with those
involved in the investigation.
2. Discuss and document the answers to the six questions in Section 5.1.1 once the
review team understands the root cause, corrective actions, level of mistake-
proofing, and improvements in detection.
The deliverable for this step is a summary of what actions will be taken systemically to
eliminate each escape, which parts the actions will be applicable to, when the actions
will be completed and by whom, and how the actions’ effectiveness will be measured.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 21


This document does not contain any export controlled technical data
As part of its standard work, UTC Aerospace Systems developed a tracking template
with automated features, which is an Excel file available from UTC Aerospace Systems
Central Quality or the Quality Authorities. Though not legible in a book format due to
its dimensions, the tracking template is shown in figure 10.

5.3 Best practices/lessons learned


Best practices and lessons learned for defining quality control actions include
1. Developing temporary containment actions to prevent escapes. ZDP is built on
the idea “you cannot inspect quality in; it must be built in with robust process-
es.” While process controls are developed and implemented, temporary con-
tainment actions should be used to prevent escapes; therefore, there is a large fo-
cus on data-driven, systemic containment due to a need to
a. Prevent escapes immediately. In a regulated industry, the process changes
needed to achieve zero defects can take months or even years. During this
time, similar defects must be prevented from becoming escapes to our cus-
tomer. These similar defects can be prevented by identifying what in our
detection systems failed to detect the defect and making our systems ca-
pable of detecting similar defects. Many recurring defects can have differ-
ing or multiple root causes, but a robust detection system can prevent es-
capes regardless of cause.
b. Identify weaknesses in both process capability and detection. The effec-
tiveness of process corrections is quantified once corrective actions are
implemented.
c. Evaluate process weaknesses. Each defect detected provides an opportuni-
ty to evaluate what process weakness resulted in the defect and if addi-
tional process improvements are required. This evaluation is what leads
from a containment/zero escape focus to process/zero defects.
2. Checking the applicability of each common quality control actions in Appendix
A to all ZDP part numbers. The bias is to apply all actions across all part num-
bers unless they are not applicable because of product type or design details.
Lack of a similar failure on a read-across part is not a reason to exclude that part
from the action.
3. Clarifying the concept of containing unknown-unknowns (or systemic contain-
ment). This concept is often confusing to teams first using the ZDP methodology,
but is critical to its effectiveness. Systemic containment actions are defined by:
a. Answering questions 1-3 of Section 5.1.1 (How did the customer find the
escape when we did not? Why, systemically, did our detection systems
not find the escape? What systemic actions will be taken to detect this type
of failure effect?)

22 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
b. Applying the systemic actions to all applicable part numbers.
c. Applying best practices to all applicable parts.
4. Defining effective quality control actions depends on having an effective cross-
functional team working together. To get the full picture of how our customers
detect escapes, the original ship site must understand the details of product de-
sign, supplier performance, manufacturing, and customer test and inspections
and rejection processes. As such, the working team should, at a minimum, in-
clude Design Engineering, Supplier Management, Manufacturing Engineering,
Operations, and Quality.
When reviewing no-fault-found (NFF) and fault-not-found (FNF) escapes, the escape
event should be reviewed to determine if the same part (same P/N and S/N) has re-
turned more than once. And if recurring escapes have occurred (i.e. intermittent failure
or other failure not detectable by current production testing), investigation should con-
tinue. Only if an FNF has no recurrences and the customer agrees it is not chargeable to
the site should it be removed from the quality control actions.
Finally, to answer the question “How did the customer find the escape when we did
not,” involving the OEM customer, the onsite representative must understand the cus-
tomer’s process at the “Gemba,” a Japanese term that means “going to the real place.”
For escapes, Gemba occurs at the customer site where the potential problem was dis-
covered. For example, Gemba may reveal that the hardware interface to the customer
application differs from that of the UTC Aerospace Systems’ assembly, inspection, and
test processes used to validate the hardware before it ships. If an OEM customer on-site
representative is unavailable, the site team may need to go to the customer’s Gemba to
answer the question.

5.4 Examples
Several examples of customer escapes and potential answers to the systemic contain-
ment questions are presented in table 3.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 23


This document does not contain any export controlled technical data
Table 3: Sample analyses of escapes

Why,
Systemic
Direct Why did the systemically,
Containment Effectiveness Read-across Read-across
Cause of customer find it did we not have
(Known- measurement ECD Scope
Escape and we didn't? detection in
Unknown)
place?

Customer scans
Automate part-
and verifies We are depend- Number of part- Over-inspect--
marking and -
electronically ing on manual marking es- 30 days with
verification;
OR one person marking and capes found at customer’s
Wrong check ID on
reads one tag verification over- technique
P/N on the seats versus 20
and another processes. In- in- Automate part-
ATR "tape”; update
reads docu- spector error-- spect/automate marking and
WI; change ID
ment, versus no inspection of d part verifica- verification--120
installation
using our man- inspection tion days
location
ual system
Potential dam- Improve parts’
Number of
age after inspec- handling post-
packag-
tion but before It is after our inspection
ing/Handling
packaging; final inspection (stowage, ship-
improvements
possible dam- point. ping containers;
identified
Damaged age by staples at handling; pack-
during receipt before No method in aging stand-
Customer re-
shipment; inspection; place for deter- ards). 30 days 20
duction initia-
various possibly not mining if our
tive
concerns using standard parts handling Gemba walk
(RI)/shipping
work for pack- and packaging post-inspection;
damage; con-
aging; possible can cause dam- adopt best prac-
centration dia-
damage during age tices across
gram of find-
packaging op- affected prod-
ings
eration ucts
No agreed-
upon cosmetic
Inspection fo- criteria between Create visual
cused on dam- customer and standard; get
age/scratch; not UTAS; lack of concurrence
Pimple on looking for visual stand- with customer; Number of
grip from inclu- ards at appro- update WI for turn- ~20 (focus on
flap sion/pimple; no priate points utilization; backs/rejections 60 days areas, not part #
inspection crite- internally. Lack quicker feed- internal and at specific)
ria for inclu- regular/quick back to site of customer
sions/pimples at feedback on issues
paint, assembly, issues that site (QIM/Worklist
or final is seeing for with photos)
update of
standards

24 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Why,
Systemic
Direct Why did the systemically,
Containment Effectiveness Read-across Read-across
Cause of customer find it did we not have
(Known- measurement ECD Scope
Escape and we didn't? detection in
Unknown)
place?

We don't check
hardness on
specific parts;
did not validate
specific
NADCAP ap-
Update FAI
proval versus
Aluminum checks to ensure
overall; did not
was not Customer per- we obtain test
review test data
heat- formed a dy- results support- FAI failures,
from AMS 2770 60 days All programs
treated to namic test and ing final mate- material escapes
as part of FAI
T6 condi- the seat failed rial condition
(buried re-
tion OR test inter-
quirements);
nally
quality test
items did not
represent pro-
duction.; no
formal work
transfer

6 Expand Actions to Enterprise Level


6.1 What it is
This action has two levels:
1. Review actions found during previous step (Define Quality Control Actions, Sec-
tion 5). Adjust action plans to cover all applicable parts.
2. Review details of the ZDP common quality control action categories (Appendix
A) as identified by reviewing all previous zero defect reviews at other sites,
businesses, and product lines. Define actions, as appropriate, across all parts.
Completing these two actions results in an implementation plan that includes owner-
ship, completion status, and completion date on a part by part/action by action basis.
Actions and processes not found in the common action categories but with the potential
for broad applications are recorded by the local team and discussed following the NAR.
The discussion focuses on whether the actions and processes should be included in the
ZDP best practices if the actions or process improvements are seen as common to and
benefitting multiple sites.

6.2 How it is done


The actions immediately defined after data review are typically for a specific part num-
ber. Additional steps are taken to expand these actions to similar parts and processes:

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 25


This document does not contain any export controlled technical data
1) Check the applicability of each site- or part-specific action identified as part of
the review to all other ZPD part numbers. The bias is to apply all actions
across all part numbers unless they are not applicable because of product
type or design details. Lack of a similar failure on a read-across part should
not exclude that part from the action.
2) Check the applicability of any PFMEA, MPRs, or statistical FAI actions or de-
ficiencies identified in Sections 4.4.1 through 4.4.3 to all ZDP part numbers.
Their systemic causes should be addressed in the appropriate standard work.
If no PFMEA exists for a ZDP part, a corrective action should be to complete a
PFMEA for each part or common process. Similarly, if no MPR exists for a
ZDP part, a corrective action should be to complete an MPR.

6.3 Best Practices as a requirement


UTC Aerospace Systems has documented in UTAS-PRO-0034 and UTAS-SCM-PRO-
0003 specific quality control actions to be implemented by all UTAS sites and suppliers,
respectively. These requirements are based on common manufacturing process gaps
identified during execution of the ZDP process across our products value streams. They
eliminate common categories of non-conforming material by
• Implementing new requirements that protect customers from known non-
conformances; and
• Enhancing and reinforcing existing requirements to ensure uniform imple-
mentation.

7 Confirm Actions through NARs


7.1 What it is
During the NAR, independent subject matter experts discuss in great detail each escape
event with the cross-functional team and challenge the defined quality control actions
to answer the question: “Will the defined quality control actions eliminate future es-
capes with similar failure defects (regardless of root cause)?” The output of the NAR is
captured in the action item template (introduced in Section 5.2).

7.1.1 Questions to ask


1. All questions posed in Section 5.1.1.
2. Will the defined quality control actions eliminate future escapes with similar
failure defects (regardless of root cause)?

26 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
3. Is the proposed quality action plan applicable and realizable within the proposed
time frame given what we know about the site, previous escape history, data
analysis, and trends?

7.2 How it is done


Prior to the NAR, the cross-functional team will have defined quality control actions
summarized in figure 9 (described in Section 5) and be prepared to participate in a deep
dive of each escape event to challenge the resultant causal actions and provide a more
deeply defined read-across action.
The cross-functional team will also be prepared to review the common best practice im-
plementation plan, by part number, with owners and dates identified.
The deliverable for this process is a summary, by escape event, of what actions will be
taken systemically to eliminate that escape, which parts the action will be applicable to,
when the action will be completed, who owns the action, how the actions’ effectiveness
will be measured, and the common best practice implementation plan.

7.2.1 Required functional participants


The NAR requires participation by independent SME along with a cross-functional
team that includes Manufacturing Engineering and Quality from the ship site, Program
Quality (if different from production site quality), and Design Engineering for the
product being reviewed. In addition, including Program Quality, Material Engineering,
Test Engineering, and Supply Chain and OEM customer onsite representation may be
necessary to develop a clear understanding of the escape event.

7.2.2 Best practices/lessons learned


Some best practices/lessons learned for confirming the quality control actions include
1. Calling a pre-NAR with Quality and/or non-advocate expert(s) to see if the team
has an accurate interpretation of the questions posed in Sections 5.1.1 and 7.1.1.
This pre-review is performed during data analysis and prior to defining all quali-
ty control action steps (Sections 5 and 6).
2. Sharing best practices from other business units (BU)/sites ZDP action implemen-
tations prior to defining all quality control actions. This sharing gives the cross-
functional team the opportunity to gain synergy by applying common best prac-
tices implemented across all BU/site ZDP.
3. Incorporating a manufacturing floor walk-through of the (manufacturing) pro-
cess as part of the NAR. Such a walk often has the greatest impact when done
about halfway through the NAR so that information from the event review can

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 27


This document does not contain any export controlled technical data
be used to focus the walk and information from the walk can contribute to the
recommendations.

8 Implement and Track Effectiveness


All actions identified and validated through the NAR process must be aggressively
tracked to completion; this requires at least weekly tracking of
 % commitment to identified quality control actions,
 % actions complete,
 quality control action estimated completion dates,
 number of quality control actions performed, and
 number of defects and/or turnbacks detected.
These data are reviewed to ensure that actions are on plan and quality control actions
are effective, and to assess if process improvements are needed and effective.

8.1 Key process steps


1. Ensure all quality control actions are identified by specific part number in a de-
tailed Rolling Action Item List (RAIL). The total number of actions is calculated
by multiplying each action defined by the number of applicable part numbers;
separating the actions between “read-across” and “site-specific” is helpful. The
detailed action RAIL is formatted to generate a high-level summary (figure 11).
All details in the tracking summary are automatically generated using the Stand-
ard Work tracking spreadsheet.
2. Whenever an action is marked as complete, the team should “take a picture” of
it. If you can take a picture, the action is likely something concrete like a design
or tooling change, a fixture, a go/no-go gage, test equipment -- these are good.
Cautioning people, training, modifying work instructions cannot be captured in
a picture and are not as effective.
Actions

Actions % Total Total


Site 1 Site 2 Site 3 Site 4 Site 5 Total ECD
Complete Complete Inspected Turnbacks
Action Category
100% Customer Interface Verification 40 44 6 3 9 102 102 100% Complete 2785 24
Automated Inspection 3 132 0 23 15 173 90 52% 10/31/2016 4212 13
Test Coverage 12 74 0 3 20 109 98 90% 6/30/2016 2156 14
Process Automation 28 44 11 3 5 91 61 67% 10/31/2016 925 0
Internal Inspection 21 112 9 27 34 203 197 97% 5/20/2016 5452 798
Supplier Over-Inspection 4 4 44 5 17 74 64 86% 10/28/2016 3415 41
Change control 1 1 11 1 1 15 15 100% Complete 3718 0
Site Specific/New read-across 41 240 26 26 21 354 155 44% 10/31/2016 7460 155
Total Actions 150 651 107 91 122 1121 782 70% 30123 1045

Figure 11: High-level tracker (“Blue Table”)

28 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
3. Define what turnback measurements will be collected for each action and estab-
lish a data collection system. Turnback data should be updated at least weekly. If
using a ring-fence approach, turnbacks should be tracked for each ring (see ex-
ample in figure 12).
4. Establish a common file location for the implementation team (e.g., SharePoint).
5. Define a plan owner for each implementation site and establish regular (at least
weekly) progress review meetings.
6. Use turnback data to prioritize process control actions per Section 9.
7. Continuously analyze turnback data for opportunities to eliminate quality con-
trol actions once process control/capability is proven.

Figure 12: Effectiveness tracking

8. Monitor lagging quality escape performance. Typically, the customer will have a
significant amount of Work in Progress (WIP) shipped prior to ZDP implementa-
tion. Escapes from this population will likely delay customer scorecard im-
provement as the non-ZDP hardware flushes from the system (this is typically on
the order of six months to one year). A best practice to get a quicker indication of
ZDP results is to track all customer escapes by ship date and correlate to ZDP
implementation. An example escape/ship date chart is shown in figure 13.
9. For each pre-implementation escape, ask “Would the current quality control ac-
tions have caught the escape?” If the answer is no, add additional quality control
actions. For each post-implementation escape, identify if it is a new learning or
ineffective implementation problem and add additional quality control actions or
ring-fence layers as necessary.
10. Independently audit implementation for effectiveness.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 29


This document does not contain any export controlled technical data
Figure 13: Escape/ship date chart

9 Implement Process Control and UPPAP


The ultimate goal of ZDP Methodology is to ensure our processes deliver world-class
quality products to our customers. While the initial data-driven quality control actions
implemented under this methodology are absolutely necessary to drive rapid im-
provement to the customer, they can be resource-intensive, unsustainable, and counter
to the principles of a lean manufacturing environment.

9.1 How it is done


To truly drive world-class, sustainable quality performance, we must drive a focused
control plan strategy that includes, but is not limited to, the following three categories
1. 100% mistake-proofing,
2. Process control, and
3. UPPAP

9.1.1 Mistake-proofing
Mistake-proofing uses wisdom and ingenuity to create devices and processes that en-
sure a task is always done correctly. Normally, it is a simple and often inexpensive way
to prevent defects or highlight a defect so that it is not passed to the next operation.
The key steps in mistake-proofing are
1. Obtain or create a flowchart of the process. Review each step, considering where
and when human errors are likely.

30 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
2. For each potential error, work back through the process to find its source.
3. For each error, think of potential ways to make it impossible for the error to oc-
cur. Consider
a. Eliminating the step that causes the error.
b. Replacing the step with an error-proof one.
c. Facilitating the correct action to be far easier than the error.
4. If we cannot make it impossible for the error to occur, think of ways to detect the
error and minimize its effects. Consider the inspection method, setting function,
and regulatory function.
5. Choose the best mistake-proofing method or device for each error. Test, then im-
plement it.
Three kinds of inspection methods provide rapid feedback:
a. Successive inspection by the next worker(s) at the next step of the process.
b. Self-inspection: workers check their own work immediately after doing it.
c. Source inspection to check that conditions are adequate before the process
step takes place. Often such checks are automatic and keep the process
from proceeding until conditions are right.

9.1.2 Process control and certification


The ultimate goal of ZDP is to produce and deliver good parts every time. Controlling
design and production processes is the most effective way to ensure that quality prod-
ucts are built and ultimately delivered. Each process should be capable of ensuring that
a good product is moved to the next step without necessitating additional inspection. A
highly capable process that is in control guarantees the quality of the product.
Pre-control is an active process control tool used to quickly check the status of a process
and identify when to continue running, adjust a process, or stop and fix a process. Us-
ing pre-control setup and running rules allows the operator to quickly decide which of
the previous actions is appropriate. Pre-control is a powerful yet simple technique that
can reduce setup time, process adjustments, and scrap, rework and repair (SRR).
Statistical Process Control (SPC) uses statistical techniques to analyze and continuously
monitor a process to control and improve it. The main objective of SPC is to have stable,
consistent processes that produce the fewest defects possible, while the central idea is to
control variation so as to avoid product defects. The two kinds of variation in any pro-
cess are common causes and special causes. Common causes refer to occurrences that
contribute to the natural variation in any process. Special causes are unusual occurrenc-
es that are not normally (or intentionally) part of the process. While some degree of
common cause variation will naturally occur in any process, identifying and eliminating
special causes of variation are important. SPC tools include

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 31


This document does not contain any export controlled technical data
 Control charts that track process statistics over time to detect the presence of spe-
cial causes variation; and
 Capability analysis that determines if the process is capable; that is, if it meets
specification limits and produces "good" parts. Improving capability reduces the
odds of producing and therefore shipping a bad part.
Process control and certification are moving into the design stages (ProCert & Design
for Six Sigma (DFSS)). By considering variations in the manufacturing processes and
product performance under various conditions, more robust products and production
processes can be designed using statistical models.

9.1.3 UPPAP
UPPAP is a set of requirements for production part approval. One of its purposes is to
determine if the organization properly understands all customer engineering design
record and specification requirements; another is to determine if the manufacturing
process can produce product consistently and meet those requirements during an actual
production run at the quoted production rate. UPPAP applies to both internal and ex-
ternal organizations supplying production parts.
UPPAP is broken out into 19 elements as shown in figure 14.
Product Definition UPPAP Special Elements
1 Released Production Drawings 11 EFP / ESA
2 Released SPD/QAD/RCC 13 Functional Testing
3 Prod. PO & Demand Fulfillment
Required Approvals
14 Special Processes & NDT
UPPAP Core Elements 15 Material Certification Documents
4 Design Risk Assessment (DRA) 16 Dimensional Raw Material Approval
5 Process Flow 17 Part Marking Approval
6 PFMEA 18 Packaging Approval
7 Process Control Plan
UPPAP Formal Approval
8 Process Readiness Study (PRS)
19 UPPAP Review and Sign-off
9 Initial Process Studies (IPS)
10 Measurement System Analysis (MSA) Process Change Management
12 Dimensional Reports (FAI + 4) Continuous UPPAP Approval State

In Place Prior to UPPAP


Limited Use Prior to UPPAP
Not in Place Prior to UPPAP

Figure 14: 19 Elements of UPPAP

The UPPAP process is executed as shown in figure 15. Major steps of UPPAP are

32 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
1. UPPAP requirement flowdown to the producer site. The producer executes the
UPPAP process as defined by ASQR-09.2 and works with the UTAS Member Fo-
cal Point (MFP) to develop the UPPAP Objective Evidence Package (OEP).
2. Producer signature of ASQR-09.2 Form 1 acknowledges the OEP is complete. The
MFP reviews the package and works with the producer to achieve an interim
approval.
3. Gap closure. Upon interim approval, the MFP works with the producer to close
the gaps identified in the interim approval required to attain full approval.
4. Approval. Once the gaps have been closed, the MFP grants full approval and the
UPPAP process is complete.
Over the life of the product, any changes to UPPAP-approved parts are processed
through the UPPAP change process and evaluated to ensure that product and process
risks have been mitigated and/or controlled and UPPAP files have been updated.
UPPAP submission levels are determined based on producer (Supplier Gold for exter-
nal producers and ACE for internal sites) performance. The amount of objective evi-
dence submitted is related to the level of performance of the producer: underperform-
ing producers require onsite reviews of all supporting UPPAP data, while Gold-
performing producers require only a copy of ASQR-09.2 Form 1.

Producer Producer
UPPAP
receives
Required executes
requirement
UPPAP

Change occurs Producer


Full or Delta submits for
UPPAP & FAI Interim
Approval

MFP reviews
package MFP reviews
package Interim
Full approval Approval
granted granted

Producer Producer executes


submits for Full UPPAP Interim
Approval Action Plan

Figure 15: UPPAP Process

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 33


This document does not contain any export controlled technical data
9.2 Best practices/lessons learned
 Perform Measurement System Analysis (MSA) on key characteristics
 Quantify and review process capabilities
 Perform root causes analyses to identify drivers of variation
 Improve key processes and those with low capabilities first
 Remove over-inspections only after processes have been shown to be highly ca-
pable
 Implement automated “real-time” solution for SPC on production floor
 Execute UPPAP on all high-risk systems, assemblies, and components
 Engineer quality at design stages
 Complete Design Failure Mode and Effects Analysis (DFMEA)
 Design robust manufacturing processes and products that are insensitive to noise
(e.g. customer usage, piece-to-piece variation, changes over time, external envi-
ronment and system interaction).

9.3 Example
Pins for a connector on an electronic motherboard were found to be below the mini-
mum specification and too short. The immediate containment plan was to perform a
100% inspection of the pins’ length until the connector build process and motherboard
assembly were in control and process capability acceptable. A process capability study
at the supplier revealed that more than half of the pins were out of specification (figure
16, a) (Cpk<0.5). Data-driven process improvement actions were then implemented to
significantly improve the process capability (figure 16, b), achieving a Cpk greater than
1.67. Quality control over-inspections were removed only after the process capability
had been validated and demonstrated to be sustainable.

LSL USL LSL USL

a) Incapable b) Capable
Figure 16: Pin length process capability

34 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
10 Driving ZDP Execution
UTC Aerospace Systems developed tools and processes to support the disciplined exe-
cution of ZDP.

10.1 Planning and execution tracking


To support the high-level tracking of ZDP execution, major ZDP steps and milestones
for each part on ZDP are reported in a table (figure 17). The table columns, from left to
right, follow the ZDP steps. Each part on ZDP gets a different tracking row for each site
where that part is built and assembled. The table is filled initially with planned comple-
tion dates and updated as new information becomes available and milestones are com-
pleted. When a milestone is completed, the corresponding cell is also colored and
thanks to the chronological order, the row should get colored from left to right and
therefore provide a quick overview of where in the ZDP process the part is. The table
should be reviewed at least weekly to ensure progression.

Figure 17: ZDP planning and execution tracker

10.2 Leading indicator tracking


Escapes and ppm metrics are lagging indicators, delayed by months if not years, and
therefore not reflective of recent progress made through ZDP. To predict upcoming re-
ductions in escapes, the following ZDP leading indicators should be reported monthly:
 Number of parts (or LRU) covered under ZDP, out of all parts (or LRU);
 Percentage of all parts (or LRU) that have had an MPR;
 Percentage of all parts (or LRU) whose PFMEAs were updated post-MPRs. This
is a percentage of the parts under ZDP, and should be no greater than the per-
centage of part with MPR;
 PFMEA risk priority number (RPN) reduction percentage. An average RPN is
calculated from the extracted top 20% RPNs of each part’s PFMEA. The average
RPN is baselined when RPN reduction tracking is initiated (see Appendix E);
 Percentage of all interface points inspected (see ZDP Common quality control ac-
tions 1a)

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 35


This document does not contain any export controlled technical data
 Number of quality control actions implemented over the number of quality con-
trol actions defined;
 Cumulative number of turnbacks resulting from the quality control actions;
 Deployment of ZDP to suppliers to UTC Aerospace Systems;
 Percentage of ZDP parts that have been audited;
 Percentage of parts with completed statistical FAIs. For the parts with completed
statistical FAIs, the percentage of features with Ppk greater than 1.67. Improve-
ment in process capabilities should be captured.
Leading indicators are summarized in a table format as shown in table 4.
Table 4: ZDP leading indicators

Target
1Q17 2Q17 July 2017 Aug. 2017
(ECD)

Average Defective Pieces/Month 5.4 5.1 4.0 3.0 -

754
LRU/Parts 712 712 712 743
(12/2017)

MPRs 70%
36% 42% 51% 52%
(% parts) (12/2017)

PFMEA (post-MPR) 70%


35% 42% 49% 50%
(% parts) (12/2017)

PFMEA RPN reduction 50%


- 3% 6% 7%
(%) (12/2017)

100%
Interface inspection (% of points) 88% 92% 96% 98%
(12/2017)

% QC Actions implemented 28% 43% 49% 55% 100%


(#implemented / #defined) (3248/11689) (4983/11689) (5719/11689) (6443/11689) (5/2018)

# Turnbacks
8,768 12,194 14,2134 16,502 -
(cumulative)

100%
% Suppliers on ZDP 70% 78% 78% 78%
(12/2017)

ZDP Audits 75%


25% 35% 38% 45%
(%) (12/2017)

Statistical FAI 33%


12% 22% 25% 27%
(% parts) (12/2017)

% Processes Ppk >1.67 for sFAI parts 72% 62% 65% 68%
-
(#above / #overall) (721/1024) (1269/2048) (1525/2504) (2102/3089)

36 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
10.3 Audits
A ZDP implementation audit is in addition to an organization’s regular QMS audits
(which may sample the ZDP process but not focus on it) and is intended to assess the
effectiveness of the implementation, identify gaps in implementation, and provide
guidance on how to close process and effectiveness gaps. This audit also verifies com-
pliance to the Quality Control Requirements defined in UTAS-PRO-0034 and UTAS-
SCM-PRO-0003, requirements for UTAS sites and UTAS Suppliers, respectively.
An audit of ZDP™ implementation requires an assessment of both the completion of
ZDP process and the effectiveness of actions taken as part of that process. By beginning
with an audit of ZDP effectiveness, the auditor can get a sense of the overall robustness
of the ZDP implementation and what specific process areas might require additional
focus.
The intent of ZDP is to have zero escapes to the customer by first ensuring we have ro-
bust quality control strategies, which prevent process escapes from getting to the cus-
tomer, in place and then improving our processes to eliminate escapes. To audit the ef-
fectiveness of ZDP we need to look at
 Customer escapes
 Effectiveness of control strategies
 Process capability
Questions to lead this effectiveness audit are
1. Do escape performance metrics from the customer show significant improve-
ment?
2. What escapes have occurred since implementation of the ZDP Control Plan?
3. Was the part shipped before or after controls were put in place?
4. Would we have expected the controls to prevent the escape?
5. Were control plans updated based on detection gaps?
6. What objective evidence was reviewed to show that the controls (Escapes, MPR,
PFMEA, SFAI) were in place?
7. Have control plans all been implemented to plan?
8. Is read-across robust?
9. For plans requiring a long lead-time to implement, are alternate short-term plans
in place?
10. How many turnbacks have been captured?
11. Have process weaknesses been identified or fixed for turnbacks?
12. Is there evidence that process improvements (for process weaknesses identified
by: Escapes, MPR, PFMEA, statistical FAI) are in place?
13. Does turnback data show that process improvements are effective?
14. Do improved processes have demonstrated 5σ capability?

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 37


This document does not contain any export controlled technical data
Compliance to the ZDP methodology is verified by completing the checklist (Appendix
B) as part of the ZDP audit.
Finally, compliance to the Quality Control Requirements defined in UTAS-PRO-0034
and UTAS-SCM-PRO-0003 is verified using the Quality Control Requirements Audit
Tool (figure 18). The audit tool ensures that the applicable Quality Control Require-
ments are or will be implemented for each part number/product family by tracking the
progress and risks to the plan during implementation. Detailed instructions on the use
of this tool are included within the tool itself.

ECD for Full # Turnbacks / # Implementations


Process # Requirements Requirement Type
Compliance # Parts / # Opportunities

1 Human review of overruled inspection Quality Control 12/22/2018 20 / 319 20 / 40


2 Look-alike part segregation Process Improvement 1/1/2021 2/1 0/1
Assembly
Hidden features inspection control
3 Quality Control TBD 3 / 1211 4/4
plans
Circuit Card Assembly 1 3D AOI Quality Control TBD 0/0 1200 / 1200

Figure 18: ZDP PRO Quality Control requirement implementation form (excerpt)

11 ZDP for New Products


The goal of ZDP is to ultimately drive lessons learned into Product Development; de-
sign quality into products; and have capable processes to produce the design defect-
free, as intended, every time.

11.1 APQP
To design quality into products, the aerospace industry has recognized Advanced
Product Quality Planning (APQP) as an important component of new product devel-
opment that is reflected in Aerospace Standard AS9145, “Requirements for Advanced
Product Quality.” UTAS customers require that their design-responsible suppliers sup-
port early identification of design risk, both inherent and incidental. If not understood
and mitigated, these risks will translate to defects and ultimately customer dissatisfac-
tion. The focus of APQP is the use of tools and methods to mitigate both design and
manufacturing risks associated with a new product or process.
APQP specifies requirements in a structured framework to plan and complete actions of
the product realization cycle necessary to ensure quality products are delivered on time,
while satisfying cost performance targets. APQP drives a quality-focused approach to
product development; with this approach, a phased planning process is used within
which specific deliverables are established, monitored, and tracked to closure and risks
are highlighted and mitigated as they are identified. PPAP is an output of APQP that
confirms that the production process has demonstrated the potential to produce prod-

38 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
ucts that consistently fulfill all requirements while operating at the customer demand
rate.
Benefits of APQP are
 Reduced complexity of product quality planning requirements to producers
 A means for organizations to easily communicate product quality planning re-
quirements to producers
 Identification and mitigation of product and process risks as early in the devel-
opment process as possible
 Early identification of required design or process changes
 Minimized post-certification changes
 Zero-defect products.
APQP has five phases starting with conceptual product needs and extending through-
out the product life cycle (figure 19). The actual duration of each phase will differ de-
pending upon the scope and timing of the specific product and/or production develop-
ment project.

Figure 19: APQP phases

Table 5 illustrates the commonalities between ZDP and APQP: both have a customer
focus, leverage lessons learned, and are risk-based continuous improvement strategies.
They also share PPAP as a requirement to ensure that all required actions are accounted
for and validated.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 39


This document does not contain any export controlled technical data
Table 5: ZDP and APQP commonalities

ZDP APQP

Customer Escape Data Analysis Customer Inputs

Quality Control Action Plan Manufacturing Control Plan

Common Quality Control Actions


Lessons Learned
Best Practices and Requirements

PFMEA Creation/Review/Update PFMEA creation/PPAP

Non-Advocate Reviews (NAR) Design Reviews

Engineering Drawing / Specification Review


Manufacturing Process Review (MPR)
Production Readiness Review (PRR)

Statistical FAI Initial Capability Studies

UPPAP PPAP

PPAP (and therefore UPPAP) is a requirement embedded in phase 4 of APQP. Its pur-
pose is to provide evidence that the organization understands all customer engineering
design records and specification requirements and that the manufacturing process can
produce product consistently while meeting those requirements during an actual pro-
duction run at the quoted production rate. This purpose is accomplished by requiring
objective evidence in 19 separate elements (figure 14).

11.2 UTAS product introduction process


UTC Aerospace Systems Product Introduction (UPI) process parallels the APQP process
structure (figure 20). As in APQP, UPI defines the methods and stages required to
smoothly transition from design to manufacturing and product launch. UPI projects in-
corporate numerous components and subassemblies and often involve extensive col-
laborations across an organization.

40 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Figure 20: UPI-APQP alignment

12 Deploying ZDP Methodology to Supply Base


Suppliers may be asked to provide a ZDP due to past quality performance or inherent
risks associated with new parts, programs, or technologies. Suppliers are encouraged to
create a plan on their own without a request from UTC Aerospace Systems.
The ZDP for suppliers follows the same process as outlined in Sections 4-9 for UTC
Aerospace Systems sites, except the section “Confirm Actions through NARs,” which
uses UTC Aerospace Systems reviewers and/or independent reviewers from the suppli-
er. The sections are written in the context where the “customer” is UTC Aerospace Sys-
tems customers and “we” or “our” is a reference to a UTC Aerospace Systems’ facility.
For a supplier using this book, the “customer” would be UTC Aerospace Systems and
“we” or “our” would be the supplier creating a ZDP.
During the process, suppliers may get guidance and direction from the Supplier Per-
formance or the Supplier Quality organization; however, the supplier (just like our own
UTC Aerospace Systems sites) is responsible for developing the plan and providing re-
quested updates to UTC Aerospace Systems. Suppliers are asked to use the ZDP tem-

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 41


This document does not contain any export controlled technical data
plate the UTC Aerospace Systems Supplier Performance or Supplier Quality organiza-
tion provides to capture analysis, actions, and effectiveness.
Suppliers should integrate the APQP methodology as part of product development and
new product introduction.

13 Summary
The rigors and challenges in the aerospace industry demand nothing less than perfect
quality every time. Although our process-focused quality strategy has proven effective
in steady, incremental improvement, additional action is needed to drive a true step-
change in our performance.
The Zero Defect strategy encompasses all ACE-driven process control actions and sup-
plements them with an aggressive, data-driven quality control strategy. This focused
quality control strategy enables more rapid results to our customers in the form of few-
er escapes and provides a more rigorous dataset to focus our process control actions.
ZDP follows a six-step methodology:
1. Analyze escape data.
2. Define quality control actions.
3. Expand actions to enterprise level.
4. Confirm actions through NAR.
5. Implement and track effectiveness.
6. Implement process control.
The disciplined execution of all steps of the ZDP will prevent defects from reaching our
customers and improve our processes to prevent the creation of defects.

13.1 Recommendations
 Implement the ZDP today to prevent escapes.
 Include all steps in the ZDP, including process control.
 Monitor progress.
 Share any new widely applicable quality control actions to expand across UTC
Aerospace Systems sites.
 Expand ZDP to UTC Aerospace Systems suppliers.

42 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Appendices

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 43


This document does not contain any export controlled technical data
44 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
A. ZDP Common Quality Control Actions
The actions defined below are best practices identified after reviewing escapes from many sites (on an escape-by-escape
basis) and defining actions determined to be beneficial to multiple sites. Each site should define its specific plan (on a
part-by-part basis) to leverage these actions. Additional best practices will be identified and added to the list as ZDP is
developed and deployed across UTC Aerospace Systems’ sites.
Reference Action Escape Preven-
What Why
# Category tion Action

The intent of this action is to physically en-


gage with every (100%) customer interface
point as part of the build and test cycle. This
includes connector keying, alignment/bolt
holes, threaded holes, alignment bins, orienta-
This action is being taken to eliminate
tion features, hydraulic fittings, etc. The go/no
the customer being the first location
100% verifica- go gages used should verify both correct loca-
where interface issues are discovered.
tion of customer tion and physical features of the interfaces. It
We have experienced examples of wrong
100% Customer interface charac- is understood that some features (i.e. locking
connector keying, missing helicoils,
1a Interface teristics w/go threads) cannot be fully engaged without
swapped connectors, miss-clocking of
Verification no-go gauges compromising the feature. In this case verifi-
assemblies, bent alignment pins, miss-
during build cation of the proper thread size and location
located mounting holes, etc. that are first
and test. and depth, without fully exercising the fea-
detected when the customer goes to in-
ture, meets the intent of this action. The full
stall our products.
set of verifications should be integrated as
much as possible into existing operations to
minimize the recurring impact. Checking
each feature as soon after it is manufactured
and stable is preferred.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 45


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action

The intent of this action is to perform a final


visual inspection of all customer interfaces
just prior to shipping. It is recognized that all
of the features will be physically verified in This action is being taken to eliminate
earlier operations by action 1a. This addition- the customer being the first location
al check is to detect any defects that can occur where interface issues are discovered.
100% Visual in-
after the physical check. Specific work in- We have experienced examples of bent
spection of Cus-
structions (based on what features could be pins, missing helicoils, mating surface
1b tomer interfaces
altered or damaged after an interface is phys- damage, damaged seals, etc. that are first
at final inspec-
ically verified) for what is to be inspected detected when the customer goes to in-
tion
should be developed for each type of custom- stall, test or use our products. The prod-
er interface. Examples include: Bent connector ucts may have passed internal tests but
pins, lost helicoils, mechanical damage, nicks been damaged due to handling after test.
and scratches, missing/damaged seals/sealing
surfaces, gear splines, alignment parkings,
mounting threads, etc.

This action is applicable to electronic circuit


card assemblies. The intent of this action is to
utilize Automated Optical inspection at the
This action is being taken to eliminate
latest point possible in the board assembly
the customer being the first location
process. Frequently AOI is performed follow-
Implement pre- where visual defects, intermittent opera-
ing Automated soldering then manual as-
Automated coat Automated tion due to poor electrical connections, or
2a sembly and rework operations take place that
Inspection Optical Inspec- functional failures due to wrong missing
are only subject to manual inspection of the
tion (AOI) component or solder defects are detect-
specific parts that are installed. The pre-coat
ed. Our test systems do not always de-
AOI provides a final opportunity to detect
tect these issues.
solder defects, wrong or missing components
and other visual defects on the entire circuit
card.

46 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
This action is applicable to electronic circuit
card assemblies. Frequently AOI is performed
This action is being taken to eliminate
only on surface mount boards because with
the customer being the first location
the variability inherent in PTH technology
AOI application where visual defects, intermittent opera-
boards not as high a percentage of compo-
to PTH (Plated tion due to poor electrical connections, or
2b nents can be verified. The intent of this action
through hole) functional failures due to wrong missing
is to utilize Automated Optical on both sur-
boards component or solder defects are detect-
face mount and plated through-hole boards.
ed. Our test systems do not always de-
At a minimum this will allow solder joints
tect these issues.
and some components to be automatically
verified
ACTION
2c ACTION DROPPED ACTION DROPPED
DROPPED

This action is applicable to electronic circuit


card assemblies. It is common in the industry
to use the engineering circuit card assembly
(CCA) definition to program an automated
assembly process and then take the code from
This action is being taken to eliminate
AOI program- automated assembly and use that to program
the customer being the first location
ming will be automated optical inspection. The intent of
where, intermittent operation due to
defined directly this is to avoid a mistake being made in au-
2d wrong/ missing component or improper-
from engineer- tomating assembly and then being carried
ly incorporated engineering changes are
ing definition over to automated inspection so that the error
detected. Test systems do not always
(BOM) goes undetected. To avoid this, for all new
detect these issues.
programs, AOI will not be based on automat-
ed assembly but based directly on engineer-
ing definition (BOM). For existing programs
the AOI code will be 100% checked back to
the engineering BOM

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 47


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
This action is being taken to eliminate
This action is applicable to electronic circuit the customer being the first location
card assemblies. Circuit card assembly pro- where, intermittent operation or work-
ducers shall utilize 3D AOI to ensure correct manship issues are detected. Our current
Implement 3- components, component placement, solder systems do not always detect these is-
dimensional joint integrity, correct heel fillets, absence of sues. 2D AOI technology looks straight
2e
AOI lifted leads, and other visually detectable de- down at the CCA. 3D AOI allows the
(3D AOI) fects per IPC-A-610. Where board geometry CCA to be inspected from many angles.
restricts access by 3D AOI methods, alterna- The intent of this change is to allow de-
tive methods of inspection such as human tection of more workmanship issues in-
visual may be necessary as a supplement cluding lifted pins and improper solder
joint formation.

Automated op-
tical inspection
for part marking

Alternate meth- The intent of this action is to perform an au-


ods: tomated inspection of all part marking prior
- Utilize 2D bar to shipping. The capability of recent optical This action is being taken to eliminate
coded or UID's character readers allows them to read part the customer finding part number, serial
to automatically marking in a comprehensive number of fonts number, UID issues. These issues in-
2f
verify part and orientations. Implementation of a vision clude duplication, missing information,
marking system and automatic comparison of what is Incorrect information, incorrect name
- Embed vali- read to the electronic work order provides the plate used, name plate missing, etc.
dated visual opportunity to eliminate human error from
image of correct part marking inspection.
marking into
inspection work
instructions
- Implement two
person verifica-
48 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
tion where first
person reads the
marking aloud
from the part
and second per-
son checks it
against the pa-
perwork
The intent of this action is to verify that if an
This action is being taken to eliminate
EC impacts fit or function of an item that the
the customer being the first location
acceptance test and or inspection process was
Assess all ECs in where, intermittent operation due to
also updated to provide verify the change is
the past three wrong/ missing component or improper-
properly incorporated. In order to assure this,
3a years for impact ly incorporated engineering changes are
100% of the EC’s over the last three years
to test and in- detected. Our test systems do not always
should be reviewed by knowledgeable test
spection detect these issues resulting in shipment
and design engineers to confirm coverage.
of the incorrect revision level of the
Where coverage is not present it shall be add-
product or improperly installed changes.
ed.
If we do not fully exercise our power
Test Coverage
This action is for products that include high electronics then units that pass all of our
power electronics. (Power electronics typical- internal acceptance testing may fail
ly include electrical power generations & dis- when exposed to full rated loads as part
Test Power Elec-
tribution and electronic actuation; it does not of installation into the aircraft. At a min-
tronic units at
typically include data systems and control imum, our ESS testing should be done at
3b sustained rated
systems) The intent of this action is to make the nominal currents and loads the
load during ESS
sure we exercise our products at full rated product is designed to see in service.
thermal cycle
power for a long enough duration and at both When this is not done power compo-
high and low temperatures to detect power nents infant mortality occurs at our cus-
related failure modes. tomers instead of being contained by our
own testing

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 49


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
In power electronics we have had several
For power elec- failures where arcing occurred at the cus-
tronics, check This action is for products that include high tomer. There were multiple root causes
and update die- power electronics. The intent of this action is that lead to the arcing but because we
lectric test for to make sure we exercise our products at full were not testing the unit or its compo-
3c
margin & loca- rated voltage both at the card and unit level nents during dielectric testing with the
tion in the build to identify failure mechanisms including Arc- proper margin based on requirements
cycle (including ing the issues were not identified until they
PWBA testing) were installed and tested by the custom-
er
This action was originally developed for elec-
tronics products but the underlying logic
should be applied to mechanical product test-
ing as well. The intent of this action is to
Review and up- make sure we: Intermittent failures, infant mortality
date ability to 1) Exercise our products with aircraft repre- and FNF returns are too common with
detect intermit- sentative conditions (thermal, vibe, power, our customers. Through RRCA many of
tent failures dur- mechanical loading, orientation, software these issues are related to our inability to
3d
ing product ac- loading, etc.) detect intermittent failures. These steps
ceptance, vibra- 2) During testing continuously monitor the will improve our ability to detect inter-
tion and thermal equipment so that intermittent failures will be mittent failures prior to delivery
testing. detected
3) Review the logic of the detection monitor-
ing to make sure there are no filters/counters
(possibly carried over from production soft-
ware) that will mask intermittent failures

50 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
This action was originally developed for elec-
tronics products but the underlying logic
should be applied to mechanical product test-
Our customer detects product failures
ing as well.
that are not detected during our current
1) Review how parts are being used by our
acceptance testing and/or environmental
OEM customers when they fail and verify
screening. Upon return, the ATP does
that our testing is at least as robust as what it
detect the failure, indicating infant mor-
is exposed to by the OEM.
tality or an original test failure miss. The
Test product in 2) Review past ESS test failure data to deter-
intent of this change is better screen for
a way that re- mine if the profile of failures indicates that all
infant mortality prior to delivery to the
flects how it will failures are detected in the early cycles or if
customer and to make sure all test fail-
be used in ser- there are many late failures. If there are late
3e ures detected are robustly investigated.
vice and accel- failures then either the number of number of
It does happen that when the customer
erates infant test cycles should be extended; or if the issue
fails a unit they are exposing it to a con-
mortality fail- is related to a specific component(s) then add
dition that was not in the original defini-
ures. component up-screening Optimize ESS test-
tion. We still want to understand and
ing cycles based on failure profile.
replicate this condition in our testing.
3) Many of our procedures dictate that the
From the customers point of view if most
last two cycles need to be failure free. In addi-
units pass this condition then the few
tion to this any failures in earlier cycles still
that fail are unacceptable (customer de-
need to be fully documented and resolved in
fines them as escapes)
the QN/MRB system. Utilize QN system and
MRB engineering to disposition all failures
(whether or not in last 2 cycles)

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 51


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action

Implement au- The intent of this action is to prevent serial


tomated serial number generation and part marking errors.
number genera- In order to achieve this, the entire process of
Our customer detects part-marking er-
tion and auto- taking the required information from the
rors at receiving inspection that we have
mated part MRP system entering it into the part making
missed. They achieve this by comparing
marking, includ- system and marking the part shall be auto-
parts received to controlling paper work.
ing duplicated mated. As a clarification – the automated pro-
This action is to make sure that when we
Process serial number cess should not involve or require use of a
4a are creating the part marking we are us-
Automation check. key board to enter data. As part of the part
ing the proper controlling information
marking process the system will check Part
with minimized opportunity for human
Require QE number - Serial number combination being
error. In addition action 2f is intended to
sign-off for any assigned to all previous P/N - S/N combina-
provide containment if any errors still
manual override tions to make sure no duplicate serial num-
occur.
or format correc- bers are issued. In the case where a manual
tion of process override is required (i.e. replacing a damaged
automation nameplate) than QE sign off will be required.

52 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
Implement au-
tomated torque-
ing (e.g. Atlas
Copco and Pin-
point software)
and daily check
of all manual
torque wrenches The intent of this action is to verify 100% of
in use torqueing operations have been completed
successfully. This includes all torques called
Alternate meth- out being performed to the proper values. By
ods: utilizing automated torque equipment in con-
1) All manual junction with a database and evaluation logic Torque escapes have led to a wide range
torque wrenches we can detect both the count and quality (run of product failures including: arcing,
will be checked in and final torque values) of torques per- fretting, failure under vibration, etc. Use
4b once per day on formed. With the proper logic this allows us of automated torque wrenches in combi-
a digital torque to know both that the right number of torques nation with monitoring software pro-
checker to verify were performed for an operation and that vides a more robust process for achiev-
torque wrench is each part was only torqued once. ing required torque values.
not significantly
out of tolerance. For manual torque wrenches, there is risk of a
2) After final wrench going significantly out of tolerance.
torqueing, all Use of a digital torque checker will eliminate
fasteners shall having to recall months of production.
be re-checked
with a torque
tool set at the
original set
point (or lower
within the speci-
fication range)

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 53


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action

The intent of this action is to assess our build


In-process in- process for points where we are about to cre-
spections of ate hidden features and make sure we have Hidden features and characteristics have
hidden features the proper inspection and documentation of resulted in infant mortality at the cus-
for workman- these features. This includes points of han- tomer. Workmanship issues once created
5a
ship, dling/assembly damage, FOD generation or and hidden can only be detected through
FOD/contaminat inclusion, incorporation of matched parts (re- use and may not be detected until after
ion, and part cording S/Ns), etc. By utilizing in-process in- delivery.
marking spections we will document key features and
conditions prior to their becoming hidden.

The intent of this action is to put standard


work in place to define the inspection and test
There are escapes generated when re-
that should be performed, following all re-
work unintentionally causes damage to
Internal Implement post- work operations, to validate that not only is
another part of the product (not under
Inspection rework inspec- the rework correct but that other parts or
5b rework) or creates some type of func-
tion & test functions (adjacent to the parts reworked)
tional interference. Without good stand-
standard work have not been un intentionally compromised.
ards for post rework test and inspection
The types of rework performed should be
these defects can escape to the customer
reviewed and standard inspection and test
processes defined for each type of rework.

This action is being taken to eliminate


Define and im-
the customer being the first location
plement visual This action is for electronic assemblies only.
where visual defects, intermittent opera-
over inspect The intent of this action is to put standard
tion due to poor electrical connections, or
5c standards fol- work in place that defines the visual inspec-
functional failures due to wrong missing
lowing all hand tion standards to be used following all hand
component or solder defects are detect-
solder opera- solder operations.
ed. Our test systems do not always de-
tions
tect these issues.

54 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
Utilize work
transfer process
This action is for capital equipment used in
(UTAS-PRO-
the manufacture and test of our products. The
0008) for all in-
intent of this action is to utilize transition
ternal equip- This action is being taken to protect
standard work in order to ensure that equip-
ment moves. against loss of manufacturing or test ca-
5d ment is validated to be the same before and
Include as part pability due to plant rearrangement or
after any moves. First piece/last piece inspec-
of the process a equipment moves.
tion can detect changes in products and pro-
last article/first
cess that is not specifically called out in speci-
article inspec-
fications or work instructions.
tion and com-
parison.
Electrical con-
nector and wire
clearance and
routing audit to
current best This action is for electronic assemblies only. This action is being taken to eliminate
practices, in- The intent of this utilize the standard work the customer being the first location
cluding, for ex- for wire routing and management (that is in where intermittent operation or func-
5e ample: clearance place for new design work) to review legacy tional failures (due to poor electrical
issues due to designs for best practices. These best practices connections, strain relief, or wire spac-
potential misas- should be included in updated work instruc- ing) defects are detected. Our test sys-
sembly & toler- tions for the legacy products. tems do not always detect these issues.
ance stackups,
wire/strain relief
escape opportu-
nities, etc.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 55


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
Physically mis-
take proof (via
mutilation or
modification)
the incorpora-
The intent of this action is to put physical mis-
tion of non-
take proofs (level I) in place to ensure that
production
hardware used to assist in production testing,
hardware (gold This action is to prevent delivery of non-
inspection or trouble shooting cannot be acci-
5f boards, inspec- production hardware in production
dently shipped as production hardware. The
tion models, products
mistake proof device is expected to make it
gear alignment
impossible to install these “gold
checkers, etc.),
boards/units” into the next higher assembly
required on the
shop floor, from
being built in to
the next higher-
level assembly.
Establish mutu-
ally agreed to
visual standards
The intent of this action is to define the cos-
for acceptable
metic standards for our product, validate
and unaccepta- This action is to eliminate a difference in
them with our customers and provide com-
ble cosmetic acceptance standards for features that
mon visual standards both parties’ inspectors.
conditions with are frequently not defined in customer
By developing agreed to visual standards
5g the customer for specifications. This lack of clear defini-
where there is frequently a disagreement on
features, parts, tion results in customer rejects that are
what is acceptable we can eliminate cosmetic
and product usually counted against our quality
escapes. This effort would be focused on
families that scores.
products and /or customers that have a histo-
have historically
ry of cosmetic turnbacks.
disputed de-
fects. (e.g. pro-
vide common
56 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
photo set to
OEM inspector
and Customer
inspector)
This action is for supplier-provided parts and
Verify best prac-
assemblies. The intent of this action is to im-
tice moisture
plement over inspection via two person des-
controls are in
ignated quality representative (DQR) review, This action is to eliminate pcb voids, in-
place for printed
or bringing in a third-party inspection or im- termittent connections, and dendritic
5h circuit board
plement 100% source inspection for parts growth. All of which can be caused by
manufacturing
deemed high risk based on UTAS or industry entrapped PCB moisture.
and assembly as
experience. This will allow detection of de-
defined by J-
fects at the point where they are manufac-
STD-033
tured and best controlled

Risk based over


This action is for supplier-provided parts and
inspection (e.g.
assemblies. The intent of this action is to im-
double DQR, This action is being taken to eliminate
plement over inspection via two person des-
3rd party, UTAS supplier escapes from ever reaching
ignated quality representative (DQR) review,
6a source) for UTAS. It is based on a risk analysis so
or bringing in a third-party inspection or im-
products with a that additional resources are focused
plement 100% source inspection for parts
history of di- where they do the most good.
deemed high risk based on UTAS or industry
Supplier mensional or
experience.
Over-Inspection visual defects.

1) UTAS review The first action requires UTAS or its repre-


of all supplier sentatives (in addition to suppliers or DQRs)
This action is being taken to eliminate
FAIs (going to perform a review of all FAIs required and
dimensional and process errors in FAI’s
6b forward) submitted. The intent of this action is to in-
that lead to undetected failures for our
2) Require that if sure that our review actions drive diligence
customers.
the part requires and compliance in the supply base. The action
heat treating or can be completed by UTAS employees or

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 57


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
welding, then: UTAS contractors.
a. The purchase
order requires The intent of the second action is to insure
that the FAI data that, for special processes that significantly
provided must impact material properties, test data is used to
include not only independently validate material characteris-
the C of C but tics
also the test data
as required in
the heat treat or
welding specif-
ic-cation.
b. The sites FAI
process includes
a step to review
required heat
treat or welding
test data, prior
to release of the
material to the
UTAS shop for
manufacturing
or assembly. If
the supplier test
data is not readi-
ly available, the
site may per-
form the test to
verify compli-
ance.

58 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page


This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
Verify all sup-
pliers for com- Verify that the buy American act has been
pliance to Buy flowed down where required to all suppliers
American Act and validate through audit that suppliers are This action is being taken to eliminate
6c
for all military compliant with the flow down. Extend Ac- escapes to the buy American act
contracts where tion/requirement to all “drop ship” suppliers
this requirement as well.
is flowed down
Verify that the buy American act has been
flowed down where required to all suppliers
Extend to all
and validate through audit that suppliers are This action is being taken to eliminate
6d drop ship sup-
compliant with the flow down. Extend Ac- escapes to the buy American act
pliers
tion/requirement to all “drop ship” suppliers
as well.
Risk-based
component This action is being taken to accelerate
screening: Up This action is for supplier provided parts and test failures of risk components to as ear-
screening based assemblies. The intent of this action is to im- ly in the process as practical. The earlier
6e upon compo- plement increased part testing/screening for failing parts can be screened from our
nent failure his- parts deemed high risk based on test failure supply chain the lower our internal costs
tory (collaborate rate, infant mortality rate, or REI findings are and the higher or chance of avoiding
with REI COTS infant failure issues.
initiative)
For all material
certificates of This action is focused around ensuring the This action is to ensure that the material
conformance the proper material properties for all products represented by the CofC is the material
supplier shall: requiring a material CofC. The key items to called out in the design. Without proper
6f - verify raw ma- verify are source of material, compliance of traceability and test results improper
terial back to the material to design requirements and knowl- material properties frequently go unde-
original mill edgeable review of material properties test tected until a product fails with the cus-
- verify CofC reports. tomer.
matches the
UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 59
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
PO/Drawing
requirement
- verify material
properties re-
port, as required
by the
material specifi-
cation
This action is to prohibit "at risk" release of
product into production (out of process, test
rig not available, production rig not available,
and inspection equipment/gauges not availa-
A controlled release process does not
Suspend use of ble). The intent of this action is to ensure out
require the same level of review and ap-
out of process of process manufacturing (which introduces
7a proval as our NCM and MRB processes.
build authoriza- process variations that can lead to escapes.) is
This greatly increases the risk of ship-
Change Control tion minimized. If required NCM and MRB pro-
ping non-conforming hardware.
cesses should be used when parts or equip-
ment are not available to follow standard
work to provide the proper review and over-
sight
Require Level 3
7b PPAP for all JSF Program Specific Program Specific
work transfers
The correct ver-
sion of software
There are many escape paths for "wrong
loaded will be
version" of software including: not
Software verified follow- This action is to protect against the wrong
properly over-writing test software,
8a Version/ ing all other software being shipped in production hard-
Loading the wrong version of flight
Load Control production and ware
software, accidently corrupting code
test software
during test/fault clearing, etc.
modifications
including: test
60 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
software loads,
fault memory
clearing, final
production load.
Verification of
the software will
be based on val-
idation of the
proper check
code (CRC,
Checksum, or
equivalent) is
both stored cor-
rectly and pass-
es internal built
in test.
If the software
version is
transmitted
from the unit for There are many escape paths for "wrong
display and/or version" of software including: not
check by any properly over-writing test software,
other hardware The software version transmitted can indicate Loading the wrong version of flight
then this trans- either the wrong software being loaded or an software, accidently corrupting code
8b
mission will be error in communicating the software loaded. during test/fault clearing, etc. In addition
verified once Both will result in a customer escape. operator entry is sometimes used to in-
final software is put the software version and this is sub-
loaded by read- ject to error that can go undetected by
ing and display- the checksum/CRC.
ing the infor-
mation transmit-
ted
UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 61
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
Eliminate metal Storage, Kitting, and in process transportation
on metal contact of parts will be reviewed to eliminate metal
Metal on metal contact can lead directly
during kitting, on metal contact both between parts and be-
to component damage, damage to coat-
9a assembly, test, tween parts and kitting or transportation fix-
ings, nicks and scratches which are re-
and transporta- tures. Care should be taken when eliminating
jected by the customer
tion of hard- metal on metal contact not to create FOD gen-
ware. eration Risk

Risk based re- Improve packaging standard work to include


view packing clear visual work instructions for packaging
Damage caused in shipping is difficult to
instructions for and incorporate appropriate best practices to
correct with the shipping carriers so our
shipping for best eliminate damage in shipping (review foam
9b packaging must be robustly designed
practices in density, labeling, use of pallets, etc.)
and executed to prevent shipping dam-
eliminating Take photographs in shipping to document
age.
Handling shipping dam- as-shipped condition for parts with a high
/Packaging/ age risk/history of shipping damage
shipping
All product
handling
equipment shall
be on a Total
Productive Ensure that part protection is maintained over
The equipment we put in place to protect
Maintenance time and to mitigate the generation of FOD as
our products can end up being a source
(TPM) schedule protective materials break down. An effective
of risk if they are not properly main-
9c to validate that way is to number all of our product handling
tained. This occurs as the protective sur-
the product pro- equipment and put it on a maintenance pro-
faces wear down and/or FOD is collected
tections are still gram similar to what is in place for manufac-
over time.
in place, free of turing equipment and gages.
contaminants,
and have not
diminished or
been damaged
62 UTC Aerospace Systems Proprietary – Subject to restrictions on cover page
This document does not contain any export controlled technical data
Reference Action Escape Preven-
What Why
# Category tion Action
over time.
"Look-alike parts" shall not be stored in adja-
Control look-
cent locations, or kitted together in the same
alike parts by
container, unless mistake proofing strategies
one of three
are implemented, such as: unique packaging,
methods:
coloring, marking, or machine reading of part Mitigate risk of an inadvertent use of
1) Physical sepa-
numbers that addresses the risk of similar look-alike parts that can result in imme-
9d ration
appearance ("look-alike parts"). diate product failures, subtle functional
2) Making them
Control of look-alike parts should include failures, or reliability impacts.
easily distin-
parts in the manufacturing and assembly pro-
guishable
cess. Parts inspected/not inspected or test-
3) Elimination of
ed/not tested are lookalike parts and should
similar parts
implement the same control methods.
Implement
Use plastic or protected metal caps to protect
proper installa- To assure O-rings are adequately pro-
O-rings from damage over threads or sharp
9e tion process and tected during installation to prevent sub-
edges. Slide/push O-rings into place (do not
tools for O-ring sequent leaks or functional failures.
roll into place).
assembly
Review items
with a high rate
of FNF and cus- High rate fault not found and customer
Perform Gemba walks at the customer to un-
Customer tomer damaged damage parts impact customer satisfac-
10a derstand and correct the source of high rate
Collaboration with customer tion & support costs and may be mask-
FNF and customer caused part returns
to identify ac- ing real part escapes/issues
tions to elimi-
nate both

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 63


This document does not contain any export controlled technical data
Page 64 of 101

B. ZDP Execution Checklist


The checklist below helps track the execution of all critical steps to ZDP. A digital file can
be obtained from UTC Aerospace Systems Central Quality and Supplier Quality.

Company Name: ____________________________________________ Date Created: ___________________

Location: __________________________________________________ Last Updated: ___________________

Project Manager Name: ______________________________________ Signature: _____________________

Use the checklist to make sure all steps of the ZDP™ are executed and documented.
United Technologies Aerospace Systems developed a tracking template to document the ZDP and its execution. The
template is available as an Excel file from UTAS Central Quality or the Quality Authorities.

To be completed by the Project Manager or Quality Authority WHILE the work is being performed.
A “No” answer to any statement requires corrective action to be taken
Yes No N/A
1. Escape Data Analysis
1.1. Pareto escapes to select part numbers and events for review based on number of occurrenc-
es, occurrences over time, customer impact, processes, defects, etc.
1.2. Summary of each escape event where the investigation is complete
1.3. Freeze processes (no change unless rigorously validated)
1.4. Immediate screening in place
1.5. New Manufacturing Process Review for each part under ZDP
1.6. In-depth review and update of PFMEA following MPR. If PFMEA does not exist, complete
PFMEA
1.7. Statistical FAI on at least 25 pieces
1.8. 100% inspection of features with incapable processes

2. Define Quality Control Actions


2.1. Each escape event to be reviewed captured in ZDP spreadsheet/template
2.2. Review of findings from previously completed RRCA activities, MPRs, PFMEAs, Statistical FAI
2.3. “6 ZDP questions” answered for each escape and quality control action captured in zero de-
fect implementation plan (including ownership, completion status, and completion date on a
part by part / action by action basis)
2.4. Review of ZDP common quality control actions for applicability to all parts
2.5. Review UTAS-PRO-0034 / UTAS-SCM-PRO-0003 requirements for applicability to all parts
2.6. Define quality control actions

3. Expand Actions to Enterprise Level


3.1. Actions expanded across all applicable parts on site (read-across)
3.2. Actions expanded across all applicable parts within business unit (read-across)
3.3. Recommendation (if applicable) for new actions to be included in list of ZDP common quality
control actions
3.4. Update zero defect implementation plan (as needed)

UTC AEROSPACE SYSTEMS PROPRIETARY.


Subject to the restriction on the title or cover page.
**Printed copies are considered UNCONTROLLED – Verify current issue before use**
4. Confirm Actions through NARs
4.1. NAR scheduled
4.2. NAR completed

5. Implement & Track Effectiveness


5.1. Defined turnback measurement for each action
5.2. Data collection system in place and turnbacks and escapes monitored
5.3. High-level summary (“Tracker”, “Blue table”) populated
5.4. Independent audits of implementation for effectiveness

6. Implement Process Control


6.1. Continuous turnback data analysis to identify process control opportunities
6.2. Systemic process improvements implemented and verified for process control and ZDP™ ef-
fectiveness

6 ZDP questions to ask


1. How did the customer find the escape when we did not?
2. Why systemically did our detection systems not find the escape?
3. What systemic actions will be taken to detect this type of failure effect in the future?
4. How many parts does this action apply to?
5. What effectiveness measure will be used to monitor the detection system and provide information on long
term process improvement?
6. What are the estimated completion dates for implementation of the control actions?

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 65


This document does not contain any export controlled technical data
C. Manufacturing Process Review for Zero Defect Plan
Guidelines
C.1 Purpose and Scope
This guidance document provides instructions for performing a Manufacturing Process
Review (MPR) as part of the Zero Defect Plan™ (ZDP™).
Goals of an MPR are to
1. evaluate if manufacturing operations and processes are capable of consistently
producing a product compliant to the design specifications, and
2. define corrective actions to mitigate the sources of variation identified as part of
the review.
An MPR is a comprehensive review of a product build and supporting processes at a spe-
cific site or supplier. It includes reviewing the design drawing & specifications, the docu-
mentation required to produce the product, and witnessing the complete set of operating
processes from receiving through product shipment. The review focuses on tracing ob-
served sources of variation directly to potentially impacted design specifications.

C.2 References
 UTAS-PRO-0031 Process Failure Mode Effects Analysis & Controlled Build Re-
quirements
 UTAS-FRM-0076 ZDP™ Manufacturing Process Review (MPR) Workbook
 UTAS-PRO-0028 Critical Characteristic Selection and Management
 UTAS-PRO-0036 International Trade Compliance for UTAS Employees and Con-
tractors
 UTAS-GUI-1000 Production Part Approval Process (UPPAP)
 UTAS-GUI-1251 The Creation of Process Flow Diagrams, PFMEAs, and Process
Control Plans
 ZDP How-to book
 UTCQR-9.1 Process Certification
 UTAS-GUI-1251 The Creation of Process Flow Diagrams PFMEAs and Process
Control Plans
 UTAS-FRM-1251 Process Control Plan

C.3 Instructions
An MPR can be initiated for any selected part or Line Replaceable Unit (LRU). The MPR
has five phases
1) Prework
a. Compile escape & yield history;

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 66


This document does not contain any export controlled technical data
b. Collect and organize design documentation and Operations (Ops) Sheets;
c. Mark up the Ops Sheets to provide traceability to the drawing location /
design specification implemented for each process step; and
d. Validate Prework actions are complete prior to the event.
2) Build review
a. Observe product process; and
b. Identify sources of variation that could lead to a non-conforming product.
3) Identify risks and assess process capability
a. Discuss observed sources of variation, group into themes, and asses risk
priority; and
b. Validate process capability data reviewed during Prework – does the doc-
umented capability align with the observations of the group?
4) Define and update corrective action plans
a. Define corrective action plans to mitigate sources of variation;
b. Update ZDP Tracker; and
c. Update PFMEAs.
5) Drive read-across and close actions
a. Ensure comprehensive read-across of lessons learned;
b. Track all actions to closure; and
c. Monitor effectiveness of process control plans and address new lessons
learned.
The second, third, and fourth phases – “Build Review”, “Identify risks and assess process
capability”, and “Define and update corrective actions” – are all performed during the on-
site event. The fifth phase, “Drive read across and close actions”, is completed post-event.
A checklist, provided in Table 6, should be completed for each part to support the execu-
tion of all MPR steps.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 67


This document does not contain any export controlled technical data
C.3.1 Pre-Work
Actions:
 Build MPR team and Document team roster inTab #3 “ZDP™ MPR Team”
of UTAS-FRM-0076.
 Assign owners for each checklist item in Section 1.0 Prework (see Table 6).
 Compile escape & yield history for target part number(s) and product
family
 Mark up Ops Sheets to call out traceability to the drawing location / speci-
fication implemented by each process step.
 Review and summarize the CTQ parts.
 Compile summary of existing process capability data per UTCQR-9.1
 Review and update PFMEA or create a PFMEA if one does not exist.
 Ensure design and operations documentation are available for the event:
Drawings, specifications, marked up Ops Sheets, routers, summary of in-
process Engineering Changes.
 Complete the MPR Scope Sheet - Tab 8A in UTAS-FRM-0076 and priori-
tize processes to observe if it is not feasible to observe them all during
event.
This phase must be completed prior to the onsite event. A meeting should be conducted
at least one week prior to the review to validate the prework actions are complete or
will be complete in time for the onsite event. Please refer to the sections below for more
details on each action.

C.3.2 Build MPR Team


The ZDP™ execution owner, or delegate, should build a team with the roles summa-
rized below. The team member names and roles will be captured in Tab#3 “ZDP™ MPR
Team” of UTAS-FRM-0076.
An MPR requires a cross-functional team with the following roles:
 MPR Team Leader
o Event owner accountable for building the team and ensuring a suc-
cessful review.
 MPR Facilitator
o MPR process expert that facilitates the event and ensures the team
adheres to the process.
 Site Event Coordinator
o Member of local team responsible for ensuring the following logis-
tics are in place: availability of onsite personnel for dates of event,

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 68


This document does not contain any export controlled technical data
availability of parts / process to observe, site access for visitors, PPE
is available for team, an approved camera / photographer is availa-
ble to take pictures of findings (if allowed by site), and a conference
room is booked for duration of the event
 Manufacturing Engineer
o Owner, or strong working knowledge, of Ops Sheets for the target-
ed part number(s)
o Responsible for marking up the Ops Sheets to provide traceability
to the drawing.
o Ability to implement actions that require changes to the Ops Sheets
 Quality Engineer
o Product expert that is responsible for the quality of the targeted
part number(s), or has strong working knowledge of the targeted
products
 Design Engineer
o Designer of the product, or the current engineer that maintains the
blue prints for the targeted part number(s).
o Responsible for pulling together relevant design documentation
during prework and supporting effort to markup Ops Sheets to
provide traceability to design specifications.
o Ability to implement Engineering Changes identified by the MPR
(if allowed by customer).
A technical non-advocate is highly recommended. The site operators and technicians
are also critical members of the event; however, the team should be mindful of the im-
pact to production schedule. The site operators and technicians work their normal shift
and provide inputs during the operations.
Individuals may fill more than one role during the event. For example, the Quality En-
gineer may also be the Site Event Coordinator and the MPR Team leader.
Ensure all team members are eligible to participate in the MPR with no unauthorized
transfers of technical data. Refer to UTAS-PRO-0036 for requirements on export author-
ization and transfers of technical data.
A kick-off meeting to align the team on goals of event, logistics, and assign roles & re-
sponsibilities is recommended two weeks prior to the onsite event / build review.
The MPR Team Leader should validate that all Prework is complete, and that any re-
quired export authorizations are in place the week prior to the onsite event / build re-
view. Required authorizations will vary based on whether the MPR is at a domestic lo-
cation with domestic participants, or if non-local nationals will participate in the review.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 69


This document does not contain any export controlled technical data
Consult with International Trade Compliance to determine specific requirements for the
review.
For Supplier MPR:
MPRs are performed under the leadership of the Supplier Development Engineer (SDE)
or Supplier identified team leader (typically a Quality Engineer or Manufacturing Engi-
neer). Team members should be selected based on their specific knowledge of the prod-
uct, understanding of product applications and experience with manufacturing opera-
tions. At a minimum, a supplier Quality Engineer and a supplier Manufacturing Engi-
neer are required to conduct a supplier MPR. A design/product engineer with product
expertise is required if the capability exists at the supplier, otherwise, the supplier
should elevate design related questions to UTAS when they arise. If a design/product
engineer is not available, then the supplier should perform an FAI to ensure the process
is capable of producing a product compliant to the design specifications. A UTAS SQE
and/or UTAS SDE is recommended for the team, but not required if a Supplier is exe-
cuting ZDP independently.

C.3.3 Assign owners for each checklist item in Section 1.0 Prework of Table 6
The ZDP™ Execution Owner for the targeted Part Number(s), or their delegate, should
review each checklist item of the Prework section (1.0) (c.f. Table 6) and assign owners
for all.
The Prework actions should be completed, reviewed, and validated a week prior to the
event. The ZDP™ MPR Facilitator is responsible for validating that the pre-work ac-
tions are complete prior to the onsite review.

C.3.4 Compile escape & yield history for target part number(s) and product
family
The owner of this action, typically a Quality Engineer, will compile the escape & yield
history of the target Part Number(s) and product family. It is recommended to present
the escape history by the DCERI categories. The team should have the Root Cause and
Corrective Action for each escape available during the event if questions come up.
If the targeted part number is top-level assembly / LRU, then the escape data analysis
should include a review of the lower level assemblies and parts produced internally
and by suppliers.

C.3.5 Mark up Ops Sheets to call out traceability to drawing location / design
specifications
The owner of this action, typically the Manufacturing Engineer, should mark-up each
operation step to identify which design specification is implemented in that step. A best

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 70


This document does not contain any export controlled technical data
practice is to capture the Drawing Sheet Number, Grid Location, and Find
Number or specification call out directly on the Ops Sheet (see red text in figure 21
). The mark-up can be handwritten on a paper copy of the Work Instruction, or any oth-
er format that is easy to follow during the event. Copies should be made for other
members of the team. All copies of technical documentation must be properly export
classified and marked for the event.

Figure 21: Example ops. sheet mark-up

The Manufacturing Engineer should validate that all operations are in compliance with
the latest revision of the drawing – this includes validating called out tool settings in the
Ops Sheets are within design specifications called out on the drawing. If the units vary
between the design specification and the Ops Sheet, the units conversion should be ver-
ified to ensure the correct value is being implemented during the production of the part.

C.3.6 Review and Summarize Critical-to-Quality (CTQ) parts


This action is typically completed by the Quality Engineer. Verify appropriate CTQ
characteristics selection per UTAS-PRO-0028. Verify if CTQ parts are identified in Ops
Sheets. Summarize gaps and provide to event leader to support the onsite Event kick-
off.
If the targeted part is considered complex, and no CTQ’s are identified, the team should
capture an action to assess if any CTQ’s should be added based on the observations
during the Build Review.

C.3.7 Compile summary of existing process capability data per UTCQR-9.1


The owner of this action, typically Manufacturing Engineering, should present a sum-
mary of available process capability data in the onsite event kick-off .

C.3.8 Review and update / create PFMEA


The Manufacturing Engineer typically owns this action. Each part should have a current
PFMEA, or equivalent, to identify and mitigate manufacturing process risks. PFMEA’s

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 71


This document does not contain any export controlled technical data
should be living documents, which are updated every time the manufacturing / assem-
bly process is modified.
If a PFMEA, or equivalent, does not exist, or if the PFMEA does not reflect the current
operations, then a PFMEA should be created prior to the MPR. If a customer commit-
ment makes it impossible to complete the PFMEA, then a ZDP™ action should be as-
signed to create a PFMEA.
The MPR is not considered closed until an up-to-date PFMEA, or equivalent, is created
and reviewed.
The Manufacturing Process Flow Diagram should be reviewed in conjunction with the
PFMEA to better understand and align risks. If a Manufacturing Process Flow Diagram
does not exist, it is recommended to create one using Tab 4A “Process Flow” of UTAS-
FRM-0076.

C.3.9 Ensure design and operations documentation are available for the event
The Manufacturing Engineer, Quality Engineer, and Design Engineer are responsible
for ensuring the following documents are available either in physical form or digitally
during the event: drawings, specifications, summary of in-process Engineering Chang-
es, marked up Ops Sheets (per C.3.5), and routers.
The team should also be able to pull up older versions of these documents during the
event in case an issue arises where the team needs to understand what was in place at
an earlier point in the program.
The drawings and marked up Ops Sheets should be available in paper copies for the
team to be able to review while on the floor.
Obtain required export authorizations (i.e. TEXPORT) if transfer of technical data or
manufacturing know-how will occur.

C.3.10 Complete MPR Scope Sheet - Tab 8A in UTAS-FRM-0076


The Manufacturing Engineer and Site Event Coordinator typically own this action.
The MPR Scope Sheet, Tab 8A in UTAS-FRM-0076, is used to identify and prioritize
which operations will be observed during an event. The columns represent the opera-
tions, and the rows represent the part numbers observed. The team may follow multiple
serial numbers, and may view the operations out of sequence. A separate table may be
required if multiple part numbers are reviewed during an event that have drastically
different operations.
Ideally, the MPR team will observe each operation from Receiving through Shipping;
however, in some cases this may not be feasible given the total operating time com-
pared to the event duration, or due to the availability of operations performed during

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 72


This document does not contain any export controlled technical data
the days of the event. If it is not feasible to view all of the operations, the team should
prioritize operations to view during the event based on escape & yield history, relative
complexity of operation, similarity to operations performed on other parts manufac-
tured at the plant, and availability to view during the dates of the event.
It is recommended to use a color code scheme to track progress throughout the event:
Green – completed observation, Yellow – considered complete by similarity; actions
from a viewed operation will be read across, Purple – operation is performed out of
house (not viewed), Orange – in house operation not viewed during event.

)
,9
,2

st
Product Family Process Matrix

(1
se

Te

e
te

te

nc
Ba

as
at

at
ty
la

la

Ba

Fe
y

Pl

Pl
ui

rB
rP

rP
ar
bl

in

ng
er

ar

er
em

ul
te

te

la
nt
g

pt

pt
l
gu

gu

Ri
ap

ap
t
Re

Co
ss

oa

a
Re

Re
Ad

Ad

Ad

Ad

+
-A

rC

EO
s

n
ub

ie
Product information

o
1

2
y

de
bl
bl

i
C
tS

ct
n

n
m
m

/
w

tio

tio

tio

tio

tio

pe
O
s
g

se

Po
se

NE
Re

ta

ta

ta

ta

ta

ng
vin

ns
As
As

lS

lS

lS

lS

lS

ng
t/

pi
ng

lI
ei

20
b-

in

ip
xi
na

na

na

na

na

na
ea

b
ec

tti

Su

Su

Pa

A3

Bo

Sh
Ki

Fi

Fi

Fi

Fi

Fi

Fi
R

Item # Product Family Part Description Part Number Op # 1 Op # 2 Op # 3 Op # 4 Op # 5 Op # 6 Op # 7 Op # 8 Op # 9 Op # 10 Op # 11 Op # 12 Op # 13 Op # 14 Op # 15 Total Ops per Part Number
Not Not
1 A320 NEO Widget X 2427 Done Done Done Similarity Done Done Similarity Similarity Done Done Similarity Done Done
Observed Observed
Not Not
2 A320 NEO Widget Y 2428 N/A Similarity NA Yes Similarity NA NA Yes Similarity NA Yes Similarity Similarity
Observed Observed

During the event debrief, the MPR Team Leader should include a recommendation on
how to handle processes not viewed. In some cases it may warrant a delta-MPR to
complete a review of the operations, in other cases a review of the escape data analysis
and the relatively complexity of the operation may lead to a recommendation to pro-
ceed with those gaps.

C.4 Build Review


Actions:
 Ensure team has appropriate PPE.
 Witness each step of the operation, per MPR Scope Sheet. Capture ob-
served sources of variation with traceability to the operating step and
drawing specification.
 Mark up the drawing after each observed operation step to track which
design features have been reviewed. Identify which design features / spec-
ifications were not addressed or observed during the build process.
 Take photographs of key findings. Ensure photography is authorized
through the site control process.
The onsite event comprises three phases: the “Build Review”, “Identify risks and assess
process capability”, and “Define and update corrective action plans” phases. These
phases are highly iterative; the team will naturally transition between them multiple
times throughout the event. Every time there is a break in action on the floor, the team
should return to the conference room to “Capture Observations and Define Corrective
Actions”. The sub-sections below provide more details on how to execute the Build Re-
view portion of the onsite event.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 73


This document does not contain any export controlled technical data
Before the team commences the Build Review, it is recommended to host an onsite kick-
off to cover the following: summarize event goals, introduce the team members, clarify
team member “roles”, review the artifacts created during the Prework phase, determine
who will carry and review the Ops Sheets and who will carry and review drawings dur-
ing the Process Build Review, summarize the local labor considerations (e.g. union vs.
non-union) and do’s and don’ts on shop floor, clarify who is approved to take photos
on the shop floor, and review Tab 7C “Questions to Consider” from UTAS-FRM-0076.
The MPR Team Leader may include additional agenda items at their discretion.

C.4.1 Ensure team has appropriate PPE


Prior to entering the shop floor, the Site Event Coordinator must ensure each partici-
pant is wearing the appropriate PPE and understands where they are permitted to
stand, and what they are or are not permitted to touch per local labor rules.

C.4.2 Witness each step of the operations, per MPR Scope Sheet and identify
sources of variation
Prior to commencing the operations, a local site leader should introduce the team to the
technicians / operators implementing the processes that will be observed throughout
the event. This introduction should clarify the goals of the event, and invite and em-
power the operator / technician to share their improvement ideas, as well as to speak up
if the team is becoming too intrusive on their ability to complete the operations on time.
Each team member should observe the operations and capture notes on potential
sources of variation that could lead to a non-conforming product. It is recommended to
capture prescriptive observations, as it can be difficult to recall the specifics of a cryptic
note at the end of a long day. Notes maintained as part of the MPR record need to be
evaluated for technical data, and export classified (i.e. xClass) and marked appropriate-
ly.
Specific team members should be assigned to actively review the marked-up Ops
Sheets, while others should actively review the drawings. Team members should be
paired up: one with Ops Sheets and the other with Drawings. This will help the team to
quickly trace the observations from the Ops Sheet down to the Drawing spec.
The team should solicit feedback from the technicians, operators, local ME’s and QE’s
on how to best minimize variation. The team should also capture observations that
could help improve the EH&S or help lean out the process. Quality is the primary focus
of the MPR; however, the team should take advantage of the diverse set of eyes viewing
the process and capture observations that will benefit the site.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 74


This document does not contain any export controlled technical data
C.4.3 Mark-up drawings after each operation observed to verify design
features reviewed
The Design Engineer should put a check mark next to each design feature / specification
on the drawing after observing its implementation during the operation.
At the end of the operations, the Design Engineer should identify all design features /
specifications that were not directly implemented by the process as a potential gap.
Likewise, if the Designer observes the technician performing an operation not called out
by the drawing, they should capture that as a gap. A real-life example of a gap observed
during a MPR is when a technician installed a washer not called out on the drawing.
The identified gaps should be reviewed with Operations and become part of the action
plan.

C.4.4 Take photographs of key findings


The site-approved photographer using a site-approved camera should take pictures of
key findings. These photos are useful to highlight a key finding in an out brief as well as
to help the team recall the specifics of an observation later on during the event. After
multiple days of observations, the photos can be instrumental to a team remembering
the specifics of an observation they captured earlier in the event. Photos must be con-
trolled to ensure that there is no unauthorized transfer of technical data.

C.5 Onsite Event – Identify risks and assess process capability


Actions:
 Capture observations from each team member in the ZDP™ MPR Rail
(Tab 9A in UTAS-FRM-0076).
 Review and group observations into common themes in the “Theme /
Grouping of Observation” column.
 Assess the priority for each observation. Escalate any non-conformances
identified that need to be immediately contained .
 Review and validate available Process Capability Data – capture any ob-
served discrepancies as observations in the ZDP™ MPR RAIL.
 Analyze and update PFMEA, or equivalent as necessary. Drive updates
into Process Control Plan (Tab 6A in UTAS-FRM-0076)
 Assess whether or not any new KPC’s should be created based on difficul-
ty of observed operations.
This phase of the event occurs in the conference room after having observed operations
on the floor (Build Review). This may be a highly iterative process that requires observ-
ing operations in the Build Review multiple times.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 75


This document does not contain any export controlled technical data
C.5.1 Capture observations from each team member in ZDP MPR RAIL
Periodically throughout the event, the team will reconvene in the conference room to
formally capture observations from each team member in the ZDP™ MPR RAIL (Tab
9A of UTAS-FRM-0076). The recommended approach is to have the MPR Event Facilita-
tor, or the MPR Team Leader go around the room and have each team member share all
of their comments / observations from a given operation or set of operations and then
move on to the next team member. For each observation, immediately capture the “Op-
eration # / Sheet of Process” and “Drawing Location (Sheet / Zone / Find # or Note)”.
This will provide traceability of the source of variation to the potential impact on the
design intent.
Drawing
Location
Operation # / (Sheet / Zone / Theme / Grouping Observation
Action ID Sheet of Find # or of Observation / Identified Risk / Gap
# Process Note) (Issue Description)
1 Engineering Change Observation/risk/gap
2 Work Instructions Observation/risk/gap
3 Engineering Change Observation/risk/gap

C.5.2 Review observations and fill out the “Theme / Grouping of


Observation” column
After the team has captured an initial round of Observations, it is recommended to cir-
cle back and identify a “Theme / Grouping of Observation”. This column is useful to
identify opportunities to define singular actions that address multiple observations.
The themes make it easier to manage driving actions to closure as each grouping is typ-
ically owned by one person or one sub-team.
The UTAS-FRM-0076 comes pre-populated with a pull-down list of Themes. However,
the team may add custom themes appropriate to their event by editing the “Action Cat-
egory” column in Tab 10 “References” of UTAS-FRM-0076.

C.5.3 Assess the priority for each observation


The team should assign a priority level for each observation / action row. The priority
options are: Escalate, High, Medium, and Low. Escalate actions are reserved for non-
conformances observed during the review that necessitate immediate resolution. In
some cases, it may be necessary to halt production if a major non-conformance is found.
Refer to Tab 9B “Example of Priority” of UTAS-FRM-0076 for more guidance on select-
ing priority. The event debrief will summarize the action items by priority.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 76


This document does not contain any export controlled technical data
C.5.4 Review and validate available Process Capability data
Review the available process capability data and have a team discussion if the empirical
data reflects the level of variation observed throughout the event. Consider adding an
action if there are significant gaps observed.

C.5.5 Analyze and update PFMEA


The team should review the PFMEA against the sources of variation identified
throughout the course of the event. The PFMEA scoring for likelihood, severity, and
ability to detect should be reviewed and updated as necessary. The team should also
discuss whether or not any risks were identified that are not currently covered by the
PFMEA. If a PFMEA does not exist, ensure an owner is assigned to drive the creation of
a PFMEA post-event. The action should include an assessment against the MPR obser-
vations.
The team should update the Process Control Plan (Tab 6A in UTAS-FRM-0076 or
UTAS-FRM-1251) accordingly. Please refer to UTAS-GUI-1251 for more guidance.

C.5.6 Assess whether or not any new Key Process Characteristics (KPC)
should be created based on difficulty of observed operations
The team should review the KPC, the complexity of the manufacturing and assembly
processes observed, and determine whether or not additional KPCs should be identified
and managed moving forward. ZDP™ Action Items should be created to implement
new KPCs, as needed.

C.6 Onsite Event – Define Corrective Action Plans


Actions:
 Translate observations into Corrective Action Plans
 Prepare and deliver event outbrief
This phase of the event occurs iteratively with the collection of observations. A general
recommendation is to hold off defining corrective actions until a good percentage of the
Process Build Review is complete for a specific part number. By waiting, the team may
see themes emerge where a single action can address the risks identified by multiple
observations.

C.6.1 Translate the observations into Corrective Action Plans


It is recommended to review the observations by the “Themes” identified in the “Theme
/ Grouping of Observation” column and define corrective actions that directly and sys-
temically address the risk captured by the observations. A single action may address

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 77


This document does not contain any export controlled technical data
multiple observations. Not all observations require an action if the team deems one is
not necessary.
The Manufacturing Engineer and Quality Engineer should help identify owners for ac-
tions that drive updates to the Ops Sheets and technician training. The Design Engineer
should help identify owners and assess what Engineering Changes are feasible given
the constraints of the program.
Observations and actions that are not directly related to Quality (e.g. EH&S, Lean op-
portunities, etc.) should be captured and provided to the local site leadership as oppor-
tunities.
The MPR Team Leader should consider whether or not a delta-MPR is required to ob-
serve operations not observed during the event, if applicable. If a delta-MPR is recom-
mended, an action should be captured in the RAIL.
The team should identify action owners prior to the end of the event. The team should
identify an owner of the entire RAIL. The RAIL owner’s job will be to follow up with
the action owners to define estimated completion dates and manage the actions to clo-
sure.

C.6.2 Prepare and deliver event outbrief


Depending on the time constraints, the team should schedule an event outbrief with the
appropriate site leadership prior to the end of the event. If this is not feasible, an out-
brief should be scheduled as soon after the event as possible. The event outbrief should
summarize the action items by utilizing the charts found in 9C “Action Item Plots” in
UTAS-FRM-0076, highlights of the major findings, and a summary of the actions / next
steps.
Review for technical data and classify as required all output documentation (xClass)
and mark all documents, including the outbrief materials

C.7 Post Event – Drive Actions to Closure


Actions:
 Immediately drive “Escalate” priority actions to closure.
 Define read-across actions for all “Escalate” and “High” priority actions to
appropriate product lines and processes.
 Disposition all "Low" priority actions - identify which ones may not get
closed due to business priority.
 Conduct regular team meetings to status and drive all of the “Escalate”,
“High”, and “Medium” priority actions to closure.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 78


This document does not contain any export controlled technical data
 Monitor effectiveness of updated process control plans and address new
lessons learned.
 Ensure any post-MPR meetings/conference calls have proper authoriza-
tion for sharing of technical data as required.
The value of an MPR is realized only when corrective actions are closed. The MPR is not
considered complete until the Escalate, High, and Medium actions are implemented.
Each Low priority actions should be dispositioned as to whether or not they will be
complete. The MPR Team Leader owns holding the action owners accountable to en-
sure they are driven to closure.
The team should define and implement methods to track the effectiveness of the new
quality control and process control actions. For example, for the quality control actions
track the # of turnbacks identified vs. # of parts inspected.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 79


This document does not contain any export controlled technical data
Table 6: MPR checklist

Owner Complete?
1.0 Prework
Form Team: Complete Tab #3 "ZDP MPR Team" of UTAS-FRM-0076
1.1
Note: a single person may cover more than one role.
1.2 Compile escape & yield history
Mark up Ops Sheets to call out traceability to drawing location / design specifica-
tion. Make physical copies for team members during review. Review Process Flow
1.3
Diagram (Tab 4 of UTAS-FRM-0076) to ensure all Significant Product Characteris-
tics are implemented.
Review and summarize Critical-to-Quality (CTQ) parts. Verify appropriate CTQ
1.4
characteristics selection per UTAS-PRO-0028
Compile summary of existing process capability data for targeted part(s) per
1.5
UTCQR-9.1
Review and update PFMEA, or equivalent, if available.
1.6
If PFMEA, or equivalent, does not exist create a ZDP Action to complete PFMEA
Ensure design and operations documentation are available for the event:
1.7 Drawings, specifications, marked up Ops Sheets (per 1.5), routers, summary of in-
process Engineering Changes
Complete MPR Scope Sheet (Tab 8A) in UTAS-FRM-0076 to identify and prioritize
1.8
which operations will be available to observe during event.

2.0 Build Review


2.1 Ensure team has appropriate PPE and is aware of shop floor rules
Witness each step of operation, per MPR Scope Sheet. Capture observations with
2.2
traceability to operation step and drawing specification.
Mark up Drawings after each operation observed to verify design features re-
viewed. Identify which design features / specifications are not addressed by build
2.3
process. (e.g. a check mark next to design spec to indicate the operation that im-
plemented is complete)
Take photos of key findings. Ensure camera and photographer are permitted to be
2.4
used on the floor.

3.0 Identify Risks and Assess Process Capability


Capture observations from each team member in the ZDP MPR RAIL (Tab 9A in
3.1 UTAS-FRM-0076). Identify the Operation step the observation was made against,
and the Design specification / drawing location impacted
Review observations and fill out the "Theme / Grouping of Observation" column
3.2
for each observation.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 80


This document does not contain any export controlled technical data
Assess the Priority for each observation (see Tab 9B for guidance).

3.3 Note: Any non-conformance observed that necessitates stopping the line should
be an Escalate and result in an immediate meeting with key personnel to develop a
go forward plan
Review and validate available Process Capability data. Identify any observed dis-
3.4
crepancies or risks, capture in ZDP MPR RAIL.
Analyze and update PFMEA, or equivalent, as necessary. Drive updates into the
3.5
Process Control Plan (Tab 6A in UTAS-FRM-0076 or UTAS-FRM-1251)
Assess whether or not any new KPC’s should be created based on difficulty of
3.6
observed operations

4.0 Define and Update Corrective Action Plans


Translate the observations into corrective action plans in ZDP MPR Rail
4.1 Note: One action may address multiple observations. Not every observation re-
quires an action
4.2 Prepare and deliver event outbrief (may be at end of event or post event)

5.0 Drive Read Across and Close Actions


5.1 Drive all "Escalate" priority actions to closure
5.2 Drive all "High" priority actions to closure
Ensure read-across of relevant "Escalate" and "High" priority actions to appropri-
5.3
ate product lines at site
Drive all "Medium" priority actions to closure - drive read-across to appropriate
5.4
product lines at site
Disposition all "Low" priority actions - identify which ones may not get closed due
5.5
to business priority
Monitor effectiveness of updated process control plans and address new lessons
5.6
learned

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 81


This document does not contain any export controlled technical data
D. Process and Failure Mode Analysis
PFMEA is a risk management tool that provides a systematic approach to identifying all
potential failure modes in a process that could result in a failure to meet product speci-
fications or requirements. A PFMEA should utilize a cross-functional team and should
always have buy in from all major departments affected by the process.

D.1 References
 AS13004 – Process Failure Mode and Effects Analysis (PFMEA) and Control
Plans (SAE)
 SAE J1739 – Potential Failure Mode and Effects Analysis in Design (Design
FMEA), Potential Failure Mode and Effects Analysis in Manufacturing and As-
sembly Processes (Process FMEA) (SAE)
 Potential Failure Mode and Effects Analysis (FMEA) Reference Manual, 4th Edi-
tion (AIAG)
 Advanced Product Quality Planning and Control Plan, 2nd Edition (AIAG)
 UTAS-GUI-1251 – The Creation of Process Flow Diagrams, PFMEAs, and Process
Control Plans

D.2 Objectives
PFMEA is an integral part of the manufacturing process review and is used to identify
all possible failure modes as well as their severity, likelihood of occurrence, and the
likelihood of detecting the failure mode. In addition to identifying failure modes, the
PFMEA also provides a structured approach to developing process improvement op-
portunities that mitigate the most serious risks and failure modes in order to limit the
likelihood that a defect reaches the next process or end customer.

D.3 Timing
PFMEA is a proactive and living tool. Ideally, this effort should be started before or at
the feasibility stage of a new product introduction and prior to tooling for production.
Early review and the analysis of new and/or revised processes allows the team to antic-
ipate, resolve or monitor potential process concerns during the manufacturing planning
stages of a new product. The PFMEA should be completed prior to tooling release. The
tooling release date is the date at which further design changes to the actual tooling be-
come difficult or impossible to incorporate beyond changes to the drawing or other
supporting documents.
Prior PFMEAs for a part or process family from similar manufacturing processes - if
available - can be used as the starting point. The prior Process FMEA or process family

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 82


This document does not contain any export controlled technical data
FMEA should be imported and up-dated in order to document those specific manufac-
turing and assembly differences between the prior and the current PFMEA.
A PFMEA should be reviewed for any engineering or process changes to assess impact
of the change to the manufacturing process. A PFMEA should be consulted as part of an
escape investigation to understand the robustness of detection controls. A PFMEA
should be reviewed, at a minimum, every two years and should be updated with any
relevant information.
A PFMEA is also updated following findings from ZDP. ZDP identifies risks in pro-
cesses at the data review stage, during MPRs, and statistical FAIs. The PFMEA needs to
be updated accordingly with these findings to reflect newly identified risks, or how
quality control and process control actions address these risks.

D.4 Process
The PFMEA process has four major phases, with corresponding sequence of steps as
shown in figure 22. The feedback loop indicates that the PFMEA is an ever-changing,
living and breathing document.

Figure 22: PFMEA steps overview

The Process Flow Diagram (UTAS-FRM-1254) should be created prior to the PFMEA as
it aids in defining the scope of the PFMEA. Without a properly defined scope a PFMEA
can be incredibly time consuming. Customer escape data from similar existing product

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 83


This document does not contain any export controlled technical data
lines can be used in order to aid in determining the scope of the PFMEA; the input and
output characteristics in the flow diagram are pulled directly over to the PFMEA in the
form of Requirements, Potential Cause(s) of Failure, & Current Preventative Controls
for each process step identified on the Process Flow Diagram.
It should be noted that PFMEA does not use row by column logic but instead uses
branching logic (figure 23). For example, each failure mode can have multiple effects
(rows), which can have multiple causes (rows) which can have multiple controls (rows).
One failure mode can be represented by a large number of rows in the PFMEA tem-
plate. This is an important consideration when using the MS Excel PFMEA template so
plan and allow enough space between operations.
The PFMEA template (UTAS-FRM-1252) is completed from left to right for each process
step. The header information should be completed for the part number under review.
The body of the template can be completed by reviewing the help comments embedded
in the column headers with an explanation of what is required for each column. Once
the PFMEA template is completed, the team should concentrate on completing a corre-
sponding Process Control Plan (PCP). The PCP template (reference UTAS-FRM-1251) is
completed from left to right for each process step requiring a control method to manage
the sources of variation that impact product characteristics. The PCP template has help
comments embedded within the column headers with an explanation of what is re-
quired for each column.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 84


This document does not contain any export controlled technical data
Figure 23: PFMEA branching logic

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 85


This document does not contain any export controlled technical data
E. RPN Reduction Calculation
The RPN reduction is a leading indicator in ZDP to summarize progress in risk reduc-
tion for multiple parts, or processes, as identified in the PFMEAs. It may be necessary to
calculate an average RPN score if multiple PFMEAs are considered, for example, look-
ing at all parts for a specific program or customer or various processes.

E.1 Calculation
The top 20% RPNs of each PFMEA are extracted and pooled. The average RPN score
from this pool is
𝑛𝑖
∑𝑚
𝑖=1 ∑𝑗=1 𝑟𝑝𝑛𝑖,𝑗
̅̅̅̅̅̅ =
𝑅𝑃𝑁
∑𝑚
𝑖=1 𝑛𝑖

where 𝑚 is the number of different PFMEAs used to form the pool, 𝑛𝑖 is the number of
RPN scores extracted from the ith PFMEA, and 𝑟𝑝𝑛𝑖,𝑖 is the jth rpn score for the ith
PFMEA.
The calculation is graphically explained in figure 24 using PFMEAs for 2 parts and 1
process (A, B and C). The top 20% RPNs of each PFMEA are extracted and added into
the pool. Since each part has a different number of RPNs, each PFMEA contributes a
different number of RPNs to the pool. ̅̅̅̅̅̅
𝑅𝑃𝑁 is the pool average.

Figure 24: Pooled average RPN calculation

E.2 Reduction calculation


The ̅̅̅̅̅̅
𝑅𝑃𝑁 reflects the current average process risk and is reflective of any actions that
have been taken at the time of the calculation. For the ZDP leading indicator, ̅̅̅̅̅̅̅
𝑅𝑃𝑁0 is
̅̅̅̅̅̅̅
calculated at a time (t=0), when the indicator is initiated. 𝑅𝑃𝑁𝑡 is an evaluation of the
risks at a later time t. The reduction in RPN is
̅̅̅̅̅̅̅
𝑅𝑃𝑁𝑡
%𝑅𝑃𝑁 = 100 (1 − )
̅̅̅̅̅̅̅0
𝑅𝑃𝑁

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 86


This document does not contain any export controlled technical data
The %RPN should be increasing over time as risk is reduced across parts and processes.
It is nonetheless possible for %RPN to decrease or become negative if new risks are
identified, or if additional parts or processes with high risks are added into the pool.

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 87


This document does not contain any export controlled technical data
F. UTC Aerospace Systems Quality Courses
Various courses relevant to ZDP are offered through the UTC Aerospace Systems’ Col-
lege of Quality and Process Excellence, and within the ACE certification program. A se-
lection is presented in table 7.
Table 7: ZDP-relevant courses

Course Title Course #

ZDP Curriculum

ZDP 101 – The why, how and when of ZDP 2957200

ZDP 102 – ZDP Methodology Overview 3458193

ZDP 201 Data Review 3473189

ZDP 202 Process Capability 3473190

ZDP 203 Control Plans 3473191

ZDP 204 Non-Advocate Review 3473192

ZDP for NAR facilitators 3473193

Processes

Process Certification Introduction (PC101) 015434

Introduction to PPAP 101 2702219

Key Characteristics & Process Certification Reviews 2684298

Process Failure Modes and Effects Analysis 1013191

ACE

RRCA/MP 101296

RRCA 201 101212

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 88


This document does not contain any export controlled technical data
G. Authors and Contact Information
This ZDP methodology book was written by the following authors from the Quality or-
ganization at UTC Aerospace Systems:

Roger Stamm, Sr. Fellow


email: roger.stamm@utas.utc.com

Arthur Blanc, Sr. Director


email: arthur.blanc@utas.utc.com

Peter Luksas, Sr. Director


email: peter.luksas@utas.utc.com

Steven Webster, Fellow


email: steve.webster@utas.utc.com

Sue Theden, Sr. Director


email: sue.theden@utas.utc.com

Kerry Duzan, Sr. Director


(Retired)

Carol Lemon, Customer Program Quality Sr. Manager


email: carol.lemon@utas.utc.com

Tom Hoffman, Sr. Director


email: tom.hoffman@utas.utc.com

UTC Aerospace Systems Proprietary – Subject to restrictions on cover page 89


This document does not contain any export controlled technical data

You might also like