FMEA – Vol. VII: “Aligned” Process Failure Modes and Effects Analysis

     To conduct a Process FMEA according to AIAG/VDA alignment, the seven-step approach presented in Vol. VI (Aligned DFMEA) is used.  The seven steps are repeated with a new focus of inquiry.  Like the DFMEA, several system-, subsystem-, and component-level analyses may be required to fully understand a process.
     Paralleling previous entries in the “FMEA” series, this installment presents the 7-step aligned approach applied to process analysis and the “Standard PFMEA Form Sheet.”  Review of classical FMEA and aligned DFMEA is recommended prior to pursuing aligned PFMEA; familiarity with the seven steps, terminology used, and documentation formats will make aligned PFMEA more comprehensible.

     Like the DFMEA form presented in Vol. VI, the “Standard PFMEA Form Sheet” (“Form C” in Appendix A of the AIAG/VDA FMEA Handbook) correlates information between steps using numbered and color-coded column headings.  The aligned PFMEA form is reproduced, in stacked format, in Exhibit 1.  In use, information related to a single issue should be recorded in one row.

     As has been done in previous “FMEA” series entries, portions of the PFMEA form will be shown in close-up, with reference bubbles correlating to discussion in the text.  Not every entry in the form is discussed in detail; some are straightforward and self-explanatory.  Consult previous installments of the “FMEA” series to close any perceived gaps in the information presented.  If further guidance is needed, several options for contacting the author are available at the end of this article.
 
Conducting an ‘Aligned’ Process FMEA
     Failure Modes and Effects Analysis is conducted in three “stages” – System Analysis, Failure Analysis and Risk Mitigation, and Risk Communication.  These three stages are comprised of the seven-step process mentioned previously.  A graphical representation of the relationships between the three stages and seven steps is shown in Exhibit 2.  For each step, brief reminders are provided of key information and activities required or suggested.  Readers should reference this summary diagram as each step is discussed in this presentation and while conducting an FMEA.

System Analysis
1st Step – Planning & Preparation
     Classical FMEA preparations have often been viewed as separate from analysis.  Recognizing the criticality of effective planning and preparation, the aligned process from AIAG and VDA formally incorporate them in the 7-step approach to FMEA.  This is merely a change in “status,” if you will, for preparatory activities.  Thus, the discussion in “Vol. II:  Preparing for Analysis” remains valid, though introduction of the tools is dispersed among steps in the aligned approach.
     Specifically, the realm of appropriate context for FMEA remains the three uses cases defined, briefly described as (1) new design, (2) modified design, or (3) new application.  Within the applicable context, the FMEA team must understand the level of analysis required – system, subsystem, or component.
     The core and extended analysis team members are chosen in the same manner as before.  Defining customers, from subsequent workstations to end user, remains integral to thorough analysis. Doing so in advance facilitates efficient analysis, with all foreseeable Effects of Failure identified.

     To state it generally, the inputs needed to conduct an effective FMEA have not changed.  However, the aligned process provides a framework for organizing the accumulated information into a coherent project plan.  Using the Five Ts structure introduced in “FMEA – Vol. V:  Alignment,” project information is presented in a consistent manner.  The scope of analysis, schedule, team members, documentation requirements, and more are recorded in a standardized format that facilitates FMEA development, reporting, and maintenance.
     Key project information is recorded on the PFMEA form in the header section labeled “Planning & Preparation (Step 1),” shown in Exhibit 3.  The labels are largely self-explanatory, though some minor differences exist between the aligned and classical forms.  One such difference is the definition of the “Subject” (1) of analysis.  On this line, identify the process analyzed by name, location (e.g. line number, department, facility), and any commonly used “nickname” needed to differentiate it from similar processes.

     Key Date on the classical form has been replaced by “Start Date” (2) on the aligned form; both refer to the design freeze date.  “Confidentiality Level” (3) has been added to the form.  Two levels are suggested in the Handbook – “Proprietary” and “Confidential” – but no further guidance on their application is provided.  Discussions should take place within an organization and with customers to ensure mutually agreeable use of these designations and information security.
     Refer to the “FMEA Form Header” section of “Vol. IV:  ‘Classical’ Process Failure Modes and Effects Analysis” for additional guidance on completing this section of the form.
 
Continuous Improvement
     The first two columns in the body of the PFMEA form, shown in Exhibit 4, are not included in the discussion of the seven steps.  The first column, “Issue #” (A), is used to simply number entries for easy reference.  The purpose of column B, “History/Change Authorization,” is left to users’ interpretation.  Presumably, it is used to record management approval of process changes or acceptance of existing risk, though the Handbook offers no guidance on this topic.  In whatever fashion an organization chooses to use this portion of the form, it should be documented in training to ensure consistency and minimize confusion.

2nd Step – Structure Analysis
     Structure Analysis may be less intuitive in a process context than it is for a physical object.  The structure hierarchy, however, remains the same:  Effects of Failure, Failure Modes, Causes of Failure.

     The Structure Analysis section of the PFMEA form is shown in Exhibit 5.  In the first column (C), identify the Process Item, “the highest level of integration within the scope of analysis.”  That is the result achieved by successful completion of all Process Steps, where Effects of Failure would be noticed.  The Process Step (D) is the focus of the analysis – a process operation or workstation where a Failure Mode occurs.
     Each Process Step may be associated with several Process Work Elements (E), where the Causes of Failure lie.  The Handbook highlights four main types (“4M Categories”) of Process Work Element:  Machine, Man, Material, and EnvironMent.  Each category is analyzed separately for each Process Step.
     To organize information needed for Structure Analysis, creating a process flow diagram (PFD) is a great place to start (see Commercial Cartography – Vol. II:  Flow Charts).  A single PFD may contain the scope of several PFMEAs, once the complexity of the system and subsystems are considered.  A complete PFD supports rational decisions (see Making Decisions – Vol. I:  Introduction and Terminology) to define a manageable scope for each analysis.
     The flow of information from process flow diagram to structure tree to PFMEA is shown in Exhibit 6.  Enter information in the PFMEA form proceeding across (left to right), then down, to ensure that each Process Work Element has been thoroughly considered before proceeding to the next Process Step.

3rd Step – Function Analysis
     Collection and organization of information to support Function Analysis can be done with a parameter diagram.  As shown in Exhibit 7, the basic layout of the process parameter diagram (P-Diagram) is the same as that of the product P-Diagram, with changes made to accommodate differing informational needs and terminology.

     The Function Analysis section of the PFMEA form, shown in Exhibit 8, is numbered and color-coded to maintain links to information in Step 2.  In the first column (F), describe the function of the Process Item at the level of integration (i.e. system, subsystem) chosen for the analysis.  Multiple functions or multiple customers may be served by a Process Item; be sure that all are included.
     In column G, describe the function of the Process Step and the Product Characteristic it is intended to spawn.  Quantitative specifications can be included, but there is a caveat.  Values defined elsewhere, such as a product drawing or process instruction, are subject to revision in the source document.  This could lead to obsolete information references in the PFMEA or frequent revisions to prevent it.
     Column H contains descriptions of Process Work Element functions and Process Characteristics they are intended to achieve.  These will correspond to the 4M Categories or other types of Process Work Elements defined in Step 2.
     Expanding the structure tree used in Step 2 to include descriptions of the function of each element allows direct transfer of information to the PFMEA form.  This information transfer is demonstrated pictorially in Exhibit 9.

     The Handbook establishes guidelines for function descriptions.  To ensure consistency and clarity, function descriptions should conform to the following:

• a verb followed by a noun (“Do this to This.”)
  
• use the verb’s base form
  
• use present tense
  
• use positive words
  
• answers the question “What does it do?” when working from right to left
  
• answers the question “How does it do it?” when working from left to right
  

     Product Characteristics are the requirements or specifications of the product design.  They may originate in legal or regulatory requirements, customer specifications, industry standards, or corporate governance (internal standards).  Product Characteristics are evaluated after the product is complete.
     Process Characteristics can be evaluated during process execution.  These are the controls that ensure that a process results in the Product Characteristics required.  They may originate from process specifications, work instructions, or other process verification documentation.
     Effort expended in Function Analysis is rewarded in the next step.  Clear, concise function descriptions expedite Failure Analysis by providing phraseology that can be duplicated while maintaining accuracy of meaning.  Diligence in this step results in a more efficient analysis overall.
 
Failure Analysis and Risk Mitigation
4th Step – Failure Analysis
     Failure Analysis is the heart of an FMEA, where a system’s failure network is established.  The links between Failure Modes, Effects of Failure, and Causes of Failure, in multiple levels of analysis, are made clear in this step.
     The definitions of Failure Mode, Effect of Failure, and Cause of Failure, in practice, remain the same as in classical FMEA.  Briefly, these are:

• Failure Mode:  the manner in which the process could cause a Product Characteristic or intended function to be unrealized, described in technical terms.
• Effect of Failure:  the result of a failure, as perceived by an internal or external customer.
• Cause of Failure:  the reason a Failure Mode occurs, described in technical terms.

The relationships between a Failure Mode, its cause, and the resultant effect creates a failure chain, as shown in Exhibit 10.  Each link in the failure chain is the consequence of the existence of the one to its right in the diagram.  That is, the Effect of Failure is the consequence, or result, of the occurrence of the Failure Mode, which is, in turn, the consequence of the existence of the Cause of Failure.

     Each element is not limited to a single failure chain.  The occurrence of a Failure Mode may be perceived in several ways (Effects of Failure) or have multiple potential causes.  A Cause of Failure may also result in several potential Failure Modes, and so on.  Proper identification of each is critical to effective analysis.

     Each failure chain is documented in a single row of the PFMEA form, in the Failure Analysis section, shown in Exhibit 11.  The form maintains the relationships within the failure chain, as shown in Exhibit 10 and discussed above.  It also maintains the numbering and color-coding convention that links Failure Analysis to Function Analysis (Step 3) and Structure Analysis (Step 2).
 
     The Failure Mode is the Focus Element of the process failure chain and, typically, the focus of process owners.  Deviations are discovered in process-monitoring data and inspection reports before customers are effected by errors.  This is, at least, the goal – to contain any failures that could not be prevented.
     Process Failure Modes vary widely, as there are many types of processes that may be the subject of analysis.  Machined components may have a feature of incorrect size or location.  Printed circuit boards could have weak solder joints.  Parts could be assembled in the wrong orientation, or missing altogether.  Threaded fasteners could be tightened to an incorrect torque.  The possibilities are seemingly endless.
     Fortunately, only a finite subset of the endless potential Failure Modes are applicable to a given process.  When one is identified, its opposite, or “mirror-image” condition (e.g. high/low, long/short, etc.), if one exists, should also be considered.  Record all Failure Modes of the Process Step in column L of Exhibit 11.  These are the negatives of the Functions of the Process Step and Process Characteristics defined in Step 3.
     Aspects of a design that increase the frequency or likelihood of process failure should be discussed with the Design Responsible individual.  For example, a part feature may be difficult to machine correctly, or an assembly may lack sufficient access space to install a required component consistently and without damage.  Collaboration between Design and Process Responsible teams, such as Design for Manufacturability and Assembly (DFMA) studies, should take place “early and often” during product development to minimize these issues and their associated cost and delays.
 
     Effects of Failure must be considered for all customers, including:

• Subsequent internal processes
• Corporate management
• OEM and supplier tiers
• Regulatory agencies
• End users (i.e. vehicle operators)
• NGOs (Nongovernmental organizations), such as environmental or other advocacy groups.

An Effect of Failure can be expressed as the negative, or inverse, of the Function of the Process Item defined in Step 3 (i.e. “Doesn’t Do this to This.”), but need not be.  Examples include:

• unable to assemble [e.g. missing part feature] (subsequent internal process)
  
• vehicle will not start [e.g. battery discharged] (end user)
  
• uncontrolled emissions [e.g. faulty filter] (regulatory agencies, NGOs)
  
• reduced throughput/productivity [e.g. insufficient space to access components] (corporate management)
  
• unable to connect [e.g. interface or connector mismatch] (OEM or next-tier supplier]
  

     If a process failure can create the same Effect as identified in the product’s DFMEA, the same wording and Severity score should be used in the PFMEA.  The diagram in Exhibit 12 demonstrates how this link between a product’s DFMEA and the analysis of a process required to produce it can manifest.

     If downstream impacts are not known, due to strict customer confidentiality, multiple-tier separation from users, or any other reason, Effects of Failure should be defined in terms of what is known.  That is, part drawings, process specifications, or other provided information should be used to describe the Effects.
     Record descriptions of Effects of Failure in column J of the PFMEA form (Exhibit 11).  Include all known Effects, identified by customer (OEM, Tier 1, end user, etc.), not only the “worst.”
 
     Causes of Failure are defined in terms of the 4M Categories or other Process Work Element types first identified in Structure Analysis (Step 2).  Deviations in the physical environment, machine settings, material usage, operator technique, or other aspects of the system could cause a process failure.  Identify those aspects that reside in the subject failure chain in column M (Exhibit 11).
 
     As is the case for the previous two steps, information can be transferred directly from the structure tree, were it created in advance, to the PFMEA form.  The Failure Analysis information transfer is shown in Exhibit 13.

     To complete the Failure Analysis step, each Effect of Failure must be evaluated and assigned a Severity (S) score.  To do this, consult the Severity criteria table, shown in Exhibit 14.  Select the column corresponding to the customer effected, then the criteria in that column that best describes the impact to that customer.  The left-most column in the row containing this description contains the Severity score for the Effect of Failure; enter the number in the PFMEA form (column K of Exhibit 11).

     If there is uncertainty or disagreement about the appropriate Severity score to assign an Effect of Failure (e.g. “Is it a 3 or a 4?”), select the highest score being considered to ensure that the issue receives sufficient attention as development proceeds.  Confidence in evaluations and scores typically increase as a design matures; concordance often follows.
     The last column of the “PFMEA Severity Criteria Table” (Exhibit 14) is left blank in the Handbook because it is not universally applicable.  An organization can record its own examples of Effects of Failure to be used as comparative references when conducting a new FMEA or to aid in training.  Examples cited for various Severity scores can provide great insight into an organization’s understanding, or lack thereof, of its customers’ perspectives.
 
5th Step – Risk Analysis
     The process development team conducts Risk Analysis to identify the controls used to prevent or detect failures, evaluate their effectiveness, and prioritize improvement activities.  Relevant information is recorded in the Risk Analysis section of the PFMEA form, shown in Exhibit 15.

     In column N, record the Process Prevention Controls incorporated to preclude activation of the failure chain.  There are three types of controls that can be implemented (poka yoke, engineering controls, and management controls); these are explained in The War on Error – Vol. II:  Poka Yoke (What Is and Is Not).  Cite only those expected to prevent the specific Cause of Failure with which they are correlated (i.e. in the same row on the form).
     Though not an exhaustive list of Process Prevention Controls, some examples follow:

• processing guidelines published by an equipment manufacturer, material supplier, industry group, or other recognized authority
• re-use of previously validated process design or equipment with history of successful service
• error-proofing (see “The War on Error – Vol. II”)
• work instructions
• equipment maintenance

     The effectiveness of Process Prevention Controls is reflected in the Occurrence (O) score.  To assign an Occurrence score to each Cause of Failure, consult the Occurrence criteria table shown in Exhibit 16.  Select the Occurrence score that corresponds to the criteria that best describes the maturity of the prevention controls.  Consider the hierarchy of controls (see “The War on Error – Vol. II”) when assigning Occurrence scores; O = 1 should be reserved for frequently verified poka yoke devices.  Engineering controls typically receive mid-range scores (e.g. O = 2 – 5), while management controls have high scores (e.g. O = 6 – 9).

     If sufficient data is available to make reasonable predictions, a quantitative method of scoring can be used.  For this, substitute one of the alternate PFMEA Occurrence criteria tables, shown in Exhibit 17, for the table of Exhibit 16.  Occurrence criteria based on production volume are shown in Exhibit 17A, while time-based criteria are shown in Exhibit 17B.  The detailed criteria descriptions are unchanged; the qualitative summary terms (high, low, etc.) are simply replaced by “incidents per 1000” estimates or time intervals.

     If the frequency of occurrence of a Cause of Failure “falls between” two Occurrence scores, or there is disagreement about the correct frequency, select the higher Occurrence score.  Additional consideration in subsequent reviews is likely to resolve the matter more efficiently than extensive debate in early stages.
     The standard and alternate PFMEA Occurrence tables have a column left blank for organization-specific examples to be recorded.  These can be used as comparative references to facilitate future PFMEA development or as training aids.
 
     In column P of the Risk Analysis section of the PFMEA form, identify the Process Detection Controls in place to warn of the existence of the Failure Mode or Cause of Failure before the part reaches a customer.  Examples include visual inspection and end-of-line testing.
     Assess the effectiveness of current detection controls according to the Detection criteria table, shown in Exhibit 18.  Select the Detection (D) score that corresponds to the Detection Method Maturity and Opportunity for Detection descriptions that most accurately reflect the state of the controls and enter it in the PFMEA form.

     If there is a discrepancy between the Detection Method Maturity and Opportunity for Detection, for example, select the higher Detection score.  As a process matures, its controls evolve.  Review in subsequent development cycles is more efficient than dwelling on the matter in early stages.
     Like the S and O tables, the D criteria table has a column left blank for organization-specific examples.  Future PFMEA development and training may benefit from the experience captured here.

     Determining the priority of improvement activities in aligned FMEA is done very differently than the classical method.  For this purpose, the AIAG/VDA Handbook introduces Action Priority (AP), where a lookup table replaces the RPN calculation of classical FMEA.  The same AP Table is used for DFMEA and PFMEA; it is reproduced in Exhibit 19.

     The AP Table is used to assign a priority to improvement activities for a failure chain.  To do this, first locate the row containing the Severity score in the S column.  Then, in the O column, find the sub-row containing the Occurrence score, then the sub-row containing the Detection score in the D column.  In this sub-row, in the Action Priority (AP) column, one of three priorities is assigned:

• H:  High Priority – actions must be taken to reduce risk or acceptance of the current process justified and approved.
• M:  Medium Priority – risk should be reduced via improvement activities or acceptance of the current process justified and approved.
• L:  Low Priority – improvement actions can be identified, but justification and approval are not required to accept the current process.

Record the Action Priority assigned on the PFMEA form (Exhibit 15).  Development of improvements and assignment of responsibility, based on the priorities assigned, takes place in the next step.
     The final column of the AP Table, “Comments,” is left blank.  Organization-specific protocols, historical projects, acceptance authority, or other information can be cited here to assist PFMEA teams in completing analyses.

     Column R (Exhibit 15) is reserved for Special Process Characteristics.  Though the text of the Handbook makes no reference to this portion of the Standard PFMEA form, it is to be used in similar fashion as in classical FMEA.  Special Characteristics do not, however, transfer from the DFMEA, as the aligned Standard DFMEA form does not include it.  See “Vol. IV:  ‘Classical’ PFMEA” for a brief discussion of Special Process Characteristics.

     Column S in Exhibit 15 is an optional entry.  “Filter Code” could be used in various ways.  Examples include:

• As a substitute for the “Classification” column when transitioning an existing design from classical to aligned format.  This may be done to remain consistent with the aligned DFMEA, if this practice was followed in that analysis.
• To assign categories to aid in resource management.  These could correspond to engineering specialties, such as manufacturing, industrial, controls, and so on.  Subspecialties, such as PLC, HMI, etc., could also be coded, if desired.
• Any creative use that assists the PFMEA owner in managing and completing the analysis or allows future analysis teams to easily search for similar issues in previous process developments.

 
6th Step – Optimization
     In the Optimization step, improvement activities are identified to reduce process risk, assigned to individuals for implementation, monitored for progress, and evaluated for effectiveness.  Relevant information is recorded in the Optimization section of the PFMEA form, shown in Exhibit 20.

     Preventive Actions (column T) are preferred to Detection Actions (column U); it is far better to eliminate an issue than to develop a better reaction to it.  The Handbook asserts that the most effective sequence of implementation is as follows:

• Eliminate or mitigate Effects of Failure via process modification [lower Severity (S), Preventive Action]
• Reduce the Occurrence (O) of Causes of Failure via process modification [Preventive Action]
• Improve the ability to detect Causes of Failure or Failure Modes [lower Detection (D), Detection Action]

Prioritizing improvements in Severity over Occurrence and Detection is consistent with the classical FMEA approach.
     The Handbook suggests five possible statuses, to be recorded in column V, for the actions defined:

• Open:  “No action defined.”
• Decision pending:  action defined, awaiting approval.
• Implementation pending:  action approved, awaiting implementation.
• Completed:  implementation complete, effectiveness documented.
• Not implemented:  action declined, current process accepted.

      Column W (Exhibit 20) is reserved for Special Product Characteristics – requirements that the customer or design team have identified as particularly sensitive to manufacturing variation.  See “Vol. III:  ‘Classical’ DFMEA” for a brief discussion of Special Product Characteristics.
     The remaining columns in the Optimization section of the PFMEA form are, essentially, carryovers from classical FMEA, with predicted AP replacing predicted RPN.  Refer to Vol. IV for further discussion of these entries.
 
Risk Communication
7th Step – Results Documentation
     Much like Planning and Preparation, Results Documentation consists of tasks that have been performed for, but often considered separate from, classical FMEA.  The aligned approach formalizes Risk Communication as an essential component of analysis by incorporating it in the Seven-Step Approach.
     A significant portion of the content of an FMEA Report, as outlined in the Handbook, is contained in the PFMEA form.  For example, the scope of analysis, high-risk failures, action prioritization, status of actions, and planned implementation dates can be culled from the form.
     A comparison of the project plan, created in Step 1, with the execution and final status of the analysis may also be a useful component of the report.  Future analysis teams may be able to apply lessons learned from deviations revealed in this assessment.
     AIAG/VDA also suggest that a commitment to review and revise the PFMEA be included in the FMEA Report.  The discussion of classical PFMEA treated this as a separate endeavor, providing further evidence of the expanse of AIAG/VDA’s efforts to create a thorough and consistent analysis process.  For further discussion on the topic, see “Review and Maintenance of the PFMEA” in FMEA – Vol. IV:  “Classical” Process Failure Modes and Effects Analysis.
 
     A Process FMEA is a valuable development and communication tool.  It ensures that the impacts of a process on customers and other stakeholders are given proper consideration.  It ensures that legal and regulatory requirements are met.  It also creates a record of development activity that can be used to refine a process, develop a new process, or train others to develop successful processes.  Practitioners are encouraged to extract maximum value from FMEA and, in the effort, possibly discover a competitive advantage for their organization.
 
     For additional guidance or assistance with Operations challenges, feel free to leave a comment, contact JayWink Solutions, or schedule an appointment.
 
     For a directory of “FMEA” volumes on “The Third Degree,” see Vol. I:  Introduction to Failure Modes and Effects Analysis.
 
References
[Link] “Potential Failure Mode and Effects Analysis,” 4ed. Automotive Industry Action Group, 2008.
[Link] “FMEA Handbook.”  Automotive Industry Action Group and VDA QMC, 2019.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com