<<< Back to Index
This Month's Article >>>

FMEA Corner 
This Month's Theme is Gathering Information
Next month's theme will be "Assembling the Correct Team"

Every month in FMEA Corner, join Carl Carlson, a noted expert in the field of FMEAs and facilitation, as he addresses a different FMEA theme (based on his book Effective FMEAs) and also answers your questions.

Questions and answers are a great way to learn about FMEAs, for both experienced and less experienced FMEA practitioners. Please feel free to ask any question about any aspect of FMEAs. Send your questions to Carl.Carlson@ReliaSoft.com, and your contact information will be kept anonymous. All questions will be answered, even if they are not featured in the FMEA Corner.

 

 

 
gather [gath-er, verb]
The Merriam-Webster Dictionary defines "gather" as "to choose and collect (things)."

 

 
information [in-fer-mey-shuhn, noun]
BusinessDictionary.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."

Gather Information

"True genius resides in the capacity for evaluation of uncertain, hazardous, and conflicting information." - Winston Churchill

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 may potentially be compromised.

Access to this information 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 meetings.

In general, the following information is important to have available to the FMEA team:

Bill of Materials

The Bill of Materials, also known as the System Hierarchy, is a key part of FMEA preparation and documentation.

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, 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.

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.

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 help to define the part characteristics, but nothing can take the place of actual parts to support the "go and see" that is essential for good dialogue.

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 dialogue.

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 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.


!FMEA Tip of the Month

Use of a "Gather Information Checklist" may be helpful to ensure important information is not missed. Checklists for System/Design FMEAs and for Process FMEAs are available for download at www.effectivefmeas.com.

In Xfmea, gathered documents can easily be attached to the Xfmea project:

FMEA attachments

By double-clicking the paper clip icon, the full list of attachments can be managed.

attachments window

*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. [Show/Hide Answers]

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.

?Something I’ve always wanted to know about FMEAs
"The important thing is not to stop questioning."  -  Albert Einstein

A reader submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@ReliaSoft.com.

For detection, is this how your product can detect the problem, such as what features are designed-in to detect the problem?

Carl: 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.


About the Author

Carl S. CarlsonCarl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 30 years of experience in reliability testing, engineering and management positions, and is currently supporting clients of ReliaSoft Corporation with reliability and FMEA training and consulting. Previous to ReliaSoft, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.

Effective FMEAsMaterial for the FMEA tips, problems and solutions is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com.

 
ReliaSoft