Imagine a team has performed a couple of failure mode and effects analyses (FMEAs) and the outcomes have been positive. In fact, the results have been so successful that the company wants to expand use of the technique enterprise-wide. How can this best be done?

This article breaks this expansion process into two stages: 1) creating an FMEA framework and 2) steps to follow for each individual FMEA project.

Stage 1: Setting Up the FMEA Framework

Design, Process or System

Most companies start their FMEA programs by performing process FMEAs. They often learn quickly that a lot of production problems can be prevented by better design. Correcting problems by design is also more cost effective. So at the start of an FMEA program, it is important to decide if the focus of the FMEAs will be design, process or system.

What will the hierarchy of FMEAs be? For example, if design FMEAs will be applied, a design verification plan and report (DVP&R) will also be needed. If focusing on process FMEAs, control plans are likely to be needed.

It is definitely not necessary to start with all three variables at the same time. But before beginning a particular project, the scope and planning for which techniques will be applied should be determined.

It is also important to consider what language will be used if an organization is internationally located or has geographically-dispersed team members. FMEAs and DVP&Rs are more likely to be developed by high-level teams and may be in the company’s default business language (often English). Control plans, however, are used on the shop floor and will be in the local language.

Standard vs. Customer-specific

FMEA is an important and effective way to establish process knowledge. To optimize the benefit of this knowledge it is useful to create standard FMEAs for individual, or groups of, process steps. The same can be done for design requirements. To create customer-specific FMEAs, use the standard FMEA as a baseline and add the customer-specific requirements. Using standard FMEAs ensures process knowledge is preserved and every customer benefits from increased process knowledge.

Who Is Going to Do What?

There are too many differences between companies to define a standard approach for FMEA deployment and management for all. That is why each company must define standards for themselves. For example, in some businesses it may seem obvious that the quality manager have the overall responsibility for FMEA. Others, however, find it is more effective to assign this responsibility to the engineering manager. From there, section managers may be responsible for the designs and processes in their sections, and engineers may be responsible for the FMEA for their designs and processes. Other employees have parts to play, however, not just in an FMEA rollout, but also in generating the FMEA and completing its recommendations. All members of this greater team should be included in the rollout; their roles and responsibilities should be made clear.

Be sure to have answers for the following:

• Who will participate on the FMEA team?
• Who will trigger the FMEA?
• Who is responsible for acting on the recommended actions?
• Who is responsible for the budget, staffing and training of the resources?
• Will senior managers have an overall steering committee that reviews the progress of the FMEA rollout? If yes, how will the senior management review the FMEA after the rollout?

Software Selection Worksheets and Ranking Criterion

It is likely that most practitioners did their first FMEAs using a standard spreadsheet and that worked fine. In considering a global rollout, however, there are some possible challenges related to using Excel. When selecting the best software to use for an organization’s FMEA, some questions to consider are:

• If a supplier to one or more industries, is the layout of the worksheet consistent with the requirements in these industries?
• If a supplier to multiple industries, are multiple formats needed?
• Do the scoring sheets make sense for the organization?

Additionally, an organization must:

• Agree upon a template.
• Ensure everybody uses the agreed template.
• Ensure the documents are all stored in an easy-to-access database.
• Determine standards for version control.
• Consider if design FMEAs will be produced in addition to process FMEAs.
• Determine how to distinguish between standard and customer-specific items without replication.
• Link between design FMEA and DVP&R as well as between process FMEA and control plans.

The more intuitive and relevant the ranking sheets are to an organization the more likely they are to be accepted and used.

FMEA Training

As part of an FMEA rollout, there will be a whole range of staff involved who have totally different backgrounds. To ensure a team has the knowledge required to successfully participate in the FMEA process, a spectrum of training programs may be needed, including the following:

• A detailed training explaining the 14 steps of FMEA implementation for quality, process and design engineers. The training should include time to practice and quickly move team members to a stage of “unconscious competence,” in which working on FMEAs becomes second nature.
• A “light” training for the senior staff that emphasizes their governance responsibilities.
• A “light” training for the support staff who will contribute to the FMEA.

Legal Considerations

In many industries, there is a lot of transparency between suppliers and customers. Customers may have access to a range of performance metrics including scrap, cycle time and process capability. Be careful who has access to an FMEA. A good FMEA will contain an organization’s “dirty laundry” – it will list the things that are good enough but could be better. To minimize the risk of an FMEA ending up in the wrong hands, consider enacting the following:

• Clear policies on who can view FMEAs, particularly in regard to customers and third parties.
• A confidentiality agreement for any third party who views the FMEA.
• Require written consent of the senior technical and legal officers before releasing an FMEA.

An As-is Process Flow

Process flow is a critical component of a process FMEA. There may already exist a process flow with all of the process steps included, but although useful as a jumping off point, what is needed is an as-is process flow. It can be created by walking through the flow on the shop floor with the production personnel. Keep an eye out for steps that may be missed in process flows, but can be significant sources of variation:

• Transportation steps
• Hold steps after cleaning
• Time delays
• Storage steps when the product (or raw materials) is subject to the variations in the weather
• Rework steps, both formal and informal
• Sources of incoming raw material. Does the raw material come from a bulk delivery or the stores?

Also consider where the process flow starts. If it starts on the production line then it is possible that variation that occurs in the stores or at the kitting steps is not being taken into consideration. While making the process flow it is also important to distinguish between the standard processes and process activities required for specific customers.

Incorporate Current Failure Information

Any organization has a huge amount of information on failure modes and potential causes. These include details of field failures and customer returns, statistical process control out-of-control points, and maintenance and breakdown reports. Frequently the severity of these items is known, but occurrence and detection information needs to be addressed. Collect this information prior to an FMEA rollout and this information can be used to proactively improve processes.

Stage 2: Steps to Follow for Each FMEA Project

Determine the Scope of the FMEA

After deciding to run a process FMEA, for example, there is more work to be done before heading into the first team meeting. It is important to define the scope of the FMEA by considering the following:

• Where will the process begin? In the stores or the kitting department? At the holding step after the previous process ends?
• If there are machines that run a range of processes, will the team begin with the process that runs the most products?
  • Or the process that generates the most defects?
  • Or the steps in the process that generate the most customer returns?

It is useful to limit the scope of the first few FMEAs to a region of the line. Those limits can help provide insight into problems that are already being addressed or that customers are reporting.

Make the Scope Visible

Have the as-is process flow available in FMEA meetings. It is important that all team members be reminded of not only the purpose of the FMEA, but also any restrictions. There will be time for another FMEA on another day to hit a part of the process that is not covered in the active FMEA.

Bring the Team Together

After establishing the process flow and transferring this to the FMEA template, start to think about the team. It is important to remember that an FMEA is a team process and the FMEA will only be as good as the team. There should be a core team who own the FMEA. In addition, there will be experts and knowledge owners who contribute as required. The core team should include the FMEA owner and an expert in running the FMEA process.

Think of the personal characteristics of the team. It is likely that a large organization has its own team-building experts; it is useful to consult with them as a team is organized.

Typically the core team will be between five and seven people. Define roles for each team member to help facilitate the FMEA activities.

Establish the Role of Suppliers

Suppliers will have a huge amount of knowledge that will be relevant to the FMEA. They will understand issues other customers have had and the sources of variation within their product. Be tactful and they will share this information and incorporate it into the FMEA. Organize a specific FMEA meeting to assess their information as it pertains to product quality. For example:

• Chemical suppliers
• Variation in composition
• Variation in contamination levels
• Raw materials
• Variation in mechanical properties
• Variation in visual properties
• Components and subsystems
• Interface requirements
• Reliability

Gather Information

Make sure all the current failure information is easily available during meetings and other FMEA planning. Not only should it be available during meetings, it should be distributed in advance of any meetings to give team members time to review this information. The available information will provoke trains of discussion and help to generate new and improved ideas.

Successful from the Start

FMEA is deceptively simple. Performing one high-quality FMEA for a problem process can be taxing. Meetings can get bogged down in debates over severity rankings. The documented process flows can be different than actual process flows. When it is time to roll the process out to a whole organization, these problems may multiply.

Follow the solutions described in this article to make not only individual FMEAs but also organization-wide FMEAs successful from the start.