FMEA – Vol. II: Preparing for Analysis

     Prior to conducting a Failure Modes and Effects Analysis (FMEA), several decisions must be made.  The scope and approach of analysis must be defined, as well as the individuals who will conduct the analysis and what expertise each is expected to contribute.
     Information-gathering and planning are critical elements of successful FMEA.  Adequate preparation reduces the time and effort required to conduct a thorough FMEA, thereby reducing lifecycle costs, as discussed in Vol. I.  Anything worth doing is worth doing well.  In an appropriate context, conducting an FMEA is worth doing; plan accordingly.

     To verify that there is an appropriate context for analysis, consider the three basic FMEA use cases:
1) Analysis of a new technology, service, process, or product design.
2) Analysis of modifications to an existing product, service, or process.
3) Analysis of an existing product, service, process, or technology placed in service in a new environment or application or with new or modified requirements.
     Each use case also defines a generalized scope of analysis.  In use case 1, the scope includes the entire product, service, process, or technology in development.  For use case 2, analysis is limited to the modifications and new characteristics, interactions, or interfaces created by them.  Analysis in use case 3 focuses on interactions with a new environment, requirements created by a new application, or other influences of new operating parameters.
     A detailed definition of scope should be drafted during analysis planning.  The product, process, etc., modifications, or new operating parameters to be reviewed should be clearly defined to ensure a proper analysis.
     Clearly defining the scope accelerates the identification of requisite expertise to conduct the FMEA.  This, in turn, expedites the identification of individuals to be invited to join a cross-functional analysis team.  The team may consist of “core” members and “extended” team members.  Core members, including the engineer or project manager with overall responsibility for the FMEA, participate in all analysis activities.  Extended team members, in contrast, join the discussions for portions of the analysis to which their specialized knowledge and experience is particularly helpful; they are then dismissed to their regular duties.  The core team members are “full-timers,” while the extended team members are “part-timers” with respect to the FMEA.
     Examples of the roles or departments that team members may be recruited – or conscripted! – from are shown in Exhibit 1.  Team members should be individuals, identified by name, membership type (e.g. core or extended), and expertise.  Individuals must be accountable for the analysis; responsibilities assigned to departments are too easily shirked!

     Additional guidance on the selection of team members can be found in Making Decisions – Vol. IV:  Fundamentals of Group Decision-Making.  Adapting the models presented in the section titled “Who should be in the decision-making group?” to the FMEA context can help build an efficient analysis team.
     Once the team has been convened, its collective expertise can be applied to the remaining preparation steps, the first of which is to identify customers.  AIAG has identified four major customers that must be considered throughout the analysis:
1) Suppliers – design decisions, process requirements, and quality standards effect suppliers’ ability to reliably deliver compliant components and services.
2) OEM manufacturing and assembly plants – the confluence of all components, functions, and interfaces that must be seamlessly compiled into an end product.
3) Regulators – failing to comply with regulatory requirements could doom any product or service offering or the provider’s operations.
4) End users – the individuals or organizations that will directly engage with a product or service.
     Considering each of these customers will lead to a more comprehensive and accurate inventory of functional requirements, failure modes, and effects.  A thorough analysis is required to develop effective controls, corrective actions, and performance predictions.
 
     Functional presentations of the information gathered during preparations are required for it to add value to the analysis.  Block diagrams, parameter (P) diagrams, schematics, bills of materials (BOMs), and interface diagrams are all valid presentation tools that support FMEA.
     Block diagrams can be developed in several formats; two examples are shown in Exhibit 2.  The purpose of a block diagram is to provide a graphical representation of the interactions of components within the scope of analysis.  As shown in the generic black box model in Exhibit 3, interactions may include transfers of material, energy, or information; an example application is shown in Exhibit 4.

     The block diagram shown in Exhibit 5 is the result of expanding the black box model of Exhibit 4 to a level of detail that can be transferred to a Design FMEA (DFMEA).  The expected magnitude of interactions – force, torque, current, etc. – and types of information to be transmitted are the functional requirements recorded in the FMEA.

     A parameter diagram, or P-Diagram, can be used to compile information describing the controlled and uncontrolled inputs to a design and its desired and undesired outputs.  This will identify control factors, noise, and “error states,” or failure modes, that can be imported into a DFMEA.  See Exhibit 6 for an example P-Diagram.

     Any information source available can be used to support an FMEA, including other analyses that have been conducted independently.  For example, design for manufacturability, assembly, service, etc. (DFX) studies, ergonomic evaluations, and reliability data from similar products will contain information relevant to the DFMEA.
     Prior to conducting a Process FMEA (PFMEA), a detailed Process Flow Diagram (PFD) should be created, covering the entire scope of analysis.  It is often at this stage that the analysis team realizes that the previously chosen scope of analysis is too broad, poorly defined, or otherwise ill-suited to an efficient PFMEA process.  Adjusting the scope and supporting documentation at this stage is much less costly than a poorly-executed PFMEA.
     Process Flow Diagrams can also be created in various formats, ranging from a simple flow chart (See Commercial Cartography – Vol. II:  Flow Charts) to a detailed input-process-output model.  An example PFD is shown in Exhibit 7.  A D•I•P•O•D Process Model can be used to supplement a simple flow chart or to populate a more-detailed diagram.  The DFMEA, historical data from similar products or processes, and other analyses should also be used in support of a PFMEA process.
 
     Preparation for Failure Modes and Effects Analysis need not be limited to the activities and tools discussed here.  Anything that supports a thorough and accurate analysis should be employed.  The broader range of reliable information used, the more successful the analysis, as can be judged by the flattened lifecycle cost curve shown in Vol. I.
 
     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] Product Design.  Kevin Otto and Kristin Wood.  Prentice Hall, 2001.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com