[Author note: This article is being published mid-month, and is part of the FMEA Preparation series. It was earlier written, but inadvertently omitted from publication, as part of this series.]
Gathering Information for FMEA Preparation
One of the most important steps in FMEA preparation is gathering all of the relevant documents and information. If this step is missed or done inadequately the FMEA meetings will be burdened with extra tasks related to missing information, the time of the subject-matter experts will be wasted, and the FMEA results potentially compromised.
“True genius resides in the capacity for evaluation of uncertain, hazardous, and conflicting information.” – Winston Churchill
gather
The Merriam-Webster Dictionary defines “gather” as “to choose and collect (things).”
information
BussinessDictionary.com defines “information” as “data that is (1) accurate and timely, (2) specific and organized for a purpose, (3) presented within a context that gives it meaning and relevance, and (4) can lead to an increase in understanding and decrease in uncertainty.”
What types of information?
In general, the following categories of information are important to have available to the FMEA team. Companies can and should provide guidelines as to the specific information that is input to new FMEAs.
Bill of Materials
The Bill of Materials, also known as the System Hierarchy, is a key part of Design FMEA preparation and documentation.
Similarly, for Process FMEAs, the Bill of Process or listing of the process steps is important preparation information.
Legal and regulatory
All relevant legal and regulatory issues and documentation need to be available to the FMEA team.
Past FMEAs
All past FMEAs for similar systems or designs or assemblies should be available to the FMEA team. A relational database best accomplishes this so that the FMEA information is easily accessible to the FMEA team.
Field history
One of the keys to successful FMEAs is using them to avoid repeating past failures. Every company experiences some field failures. The most successful companies do not repeat them. The FMEA team needs to ensure that a summarized list of field failures for similar products is easily available during the FMEA project. This listing of field failures can be “seeded” into the FMEA so the team ensures these failures do not repeat.
To do this, the FMEA team needs access to field service and repair information for similar systems and designs. Field data may be culled for pertinent material, eliminating the irrelevant information, in order to easily identify field failure modes and causes that are useful to the FMEA team.
For Process FMEAs, past manufacturing or assembly issues, within the scope of the Process FMEA, is important input to new Process FMEAs.
Technical requirements and specifications
Within the scope of the FMEA project, the FMEA team requires access to all technical requirements and specifications, including functional and performance requirements, customer usage requirements and operating environments. These help define the functions as well as the operating conditions and profiles for the items under consideration.
For Process FMEAs, access to Operating Instructions is a necessary input.
Actual parts
For System or Design FMEAs, it is important to bring to the FMEA meetings actual parts that are as close to the design or process intent as possible. If actual parts are too large to bring to the FMEA meetings, then the FMEA team should arrange to see actual parts on site. For new projects that are in the early design stage and do not have prototype parts available, similar parts from previous versions suffice for this step. Schematics and drawings can supplement, but nothing can take the place of actual parts to support the “go and see” that is essential for good dialog.
For Process FMEAs, the FMEA team may need to arrange a plant visit to go and see the manufacturing or assembly operations under review. If the manufacturing operations are in the preliminary stage and there are no similar operations to see, then the FMEA team can develop visual aids for the “go and see” that supports good dialog.
Actual parts create a focal point for discussion, and allow the FMEA team to see the interfaces and visualize the functionality. This helps the team focus their attention on areas of concern, rather than imagining how the parts function and are connected.
Test procedures and test plans (For System/Design FMEAs)
The System/Design FMEA teams need access to up to date test plans and test procedures in order to be able to assess detection related risk, and recommend appropriate changes.
Process Control Plans and procedures (For Process FMEAs)
The Process FMEA teams will need access to up to date Process Control Plans and procedures in order to be able to assess detection related risk, and recommend appropriate changes.
List of specific design or process changes
In many cases, specific changes to a design or manufacturing process are being considered and will be analyzed by the FMEA team. The nature of the proposed changes must be documented and made available to the FMEA team. This includes changes in design, material, manufacturer, supplier, supplier design or process, usage environment, interfaces, specifications, performance requirements, or any other changes.
Other
Examples of other preparations include design drawings, assembly drawings, preliminary test results, marketing analysis, and so on. Each company should develop its own list of preparation items for FMEA projects. The whole idea is to get the homework and preparation done in advance of the FMEA meetings in order to best utilize the subject-matter experts’ time and contributions.
How should information be attached to FMEA?
The information that is gathered as part of FMEA preparation can be either printed matter or electronic, although it is preferred that the information is electronically available. Ideally, whoever is assigned responsibility for FMEA preparation will attach the documents and information to the FMEA project electronically, so the data is easily available to the FMEA team during team meetings.
FMEA Tip
Use of a “Gather Information Checklist” may be helpful to ensure important information is not missed. Gather Information Checklists for System/Design FMEAs and for Process FMEAs are available for download at www.effectivefmeas.com. They can be tailored to the specific needs of your company.
Problem
The Widget development team is preparing to conduct a Widget Design FMEA. Which of the following would be important items to consider for the “gather information” step? (Select all that apply)
1. Past Widget FMEAs
2. Contact information for the Widget FMEA team
3. Widget warranty and customer service history
4. Widget test procedures
5. Test procedures for non-widget systems and components
6. The company organization structure
7. Technical specifications for the Widget
8. Sourcing costs for the Widget
9. Schematics of all subsystems outside the scope of the FMEA
10. Widget drawings
11. All FMEAs in the company archive
12. Actual Widget parts
Solution
1. Past Widget FMEAs – yes
2. Contact information for Widget FMEA team – this may be included in the FMEA analysis, but is not typically part of the “gather information” step
3. Widget warranty and customer service history – yes
4. Widget test procedures – yes
5. Test procedures for non-widget systems and components – not needed
6. The company organization structure – not needed
7. Technical specifications for the Widget – yes
8. Sourcing costs for the Widget – not needed
9. Schematics of all subsystems outside the scope of the FMEA – not needed
10. Widget drawings – yes
11. All FMEAs in the company archive – not needed
12. Actual Widget parts – yes
Reader Question
For detection, is this how your product can detect the problem, such as what features are designed-in to detect the problem?
My Response
I’ll answer your question beginning with the definition of detection and detection-type controls, as well as an excerpt from my book on the use of detection scale for assessing risk related to in-service detection systems.
Detection is a ranking number associated with the controls from the list of detection-type controls, based on the criteria from the detection scale.
Detection-type design controls describe how a failure mode or cause in the product design is detected, based on current or planned actions, before the product design is released to production, and are used as input to the detection ranking.
A unique application of detection scale is used in industries where the emphasis needs to be on detecting failures once the customer takes ownership (or the system is in operation), and less focus on detecting failures during product development. One example is an oil rig in which the emphasis is on detecting and mitigating failures during operation of the oil rig system. Another example is a warning system in a nuclear power plant in which sensors detect an emerging problem, alerting personnel who can then prevent the problem or avert it before an accident or serious consequence occurs. The scale assesses the likelihood of the monitoring-type control to detect the problem during system operation. The nature of the application should determine the specific criteria of this unique detection scale.
You asked, “Is detection how your product can detect the problem, such as what features are designed-in to detect the problem?” The answer is only if you are using what is called “In-service Detection Systems” (reference the excerpt above). Otherwise, it is about the methods that are currently planned or in place to detect the problem during product development timeframe, before product launch.
Leave a Reply