Featured Product
This Week in Quality Digest Live
Lean Features
Etienne Nichols
It’s not the job that’s the problem. It’s the tools you have to do it with.
Chris Caldwell
Significant breakthroughs are required, but fully automated facilities are in the future
Megan Wallin-Kerth
Or, how mistakes factor into a kaizen mindset
Eric Whitley
Manufacturing methods and technologies that improve waste management
Donna McGeorge
Design the day for maximum productivity with this Nano Tool

More Features

Lean News
Embrace mistakes as valuable opportunities for improvement
Introducing solutions to improve production performance
Helping organizations improve quality and performance
Quality doesn’t have to sacrifice efficiency
Weighing supply and customer satisfaction
Specifically designed for defense and aerospace CNC machining and manufacturing
From excess inventory and nonvalue work to $2 million in cost savings
Tactics aim to improve job quality and retain a high-performing workforce
Sept. 28–29, 2022, at the MassMutual Center in Springfield, MA

More News

Michael Ray Fincher


Same Old Routine With FMEA?

Not with ISO 9001:2015

Published: Monday, June 26, 2017 - 11:02

To meet the 2018 deadline for becoming certified to ISO 9001:2015, organizations are scrambling to overhaul their quality management systems. One major revision to ISO 9001 is the requirement to identify, evaluate, and address risks. Unfortunately, a tool most appropriate for these actions has fallen to the wayside. Failure mode and effects analysis (FMEA) is the perfect tool to satisfy an organization’s risk analysis needs—provided that the technique is understood.

I find it bizarre that organizations which have been submitting production part approval process (PPAP) documents to their customers for more than 20 years still have no true understanding of one of the most beneficial tools in the advanced product quality planning (APQP) tool box, the FMEA. My colleague Cor Toncray and I spent almost six months reaching out to our top suppliers trying to get a better understanding of how they are using FMEA to assess and evaluate risks. We were curious as to how they were incorporating it into their risk analysis processes so they would be compliant to the revised ISO 9001 standard. We both assumed our suppliers were using FMEA as the driving force to assess and evaluate their risks and were somewhat shocked to find out they were not. We were even more shocked to find a majority of them did not truly understand FMEA at all.

Have you ever played the Telephone game? That’s the one where someone whispers a phrase into another person’s ear, and that person must in turn whisper to another person, and so on and so on. When the last person is told the phrase, he must repeat what he was told out loud, with often hilarious results. Never have I played that game when the last person in the chain could repeat the phrase anywhere close to what it was supposed to be.

This is what I believe has occurred in many organizations when it comes to how to use FMEA properly. Over the years true FMEA has evolved into just another stack of papers to submit to the customer as part of the PPAP process. It appears our FMEA experts may have actually evolved into paperwork experts, and the function of FMEA has been forgotten.

What is FMEA?

Cor and I set out to develop a training course that would define exactly what FMEA and its true purpose are. We also decided that we needed to establish a description of FMEA so our suppliers could understand it for what it was actually designed to be. Our objective was to take this training out to our suppliers and teach them not only what FMEA was, but how it should be applied within the suppliers’ organizations.

FMEA is a simple tool used to identify potential process function failures that could occur within a process. It’s a process development tool that helps assess and evaluate risks, as well as how to prevent those risks from occurring. FMEA’s primary purpose is to treat risks by designing the process to eliminate potential process function failures. Remember, the FMEA is one of the core tools in the APQP tool box used to drive the development of  process design. By identifying potential risks, our expectations are to prevent or reduce those risks by designing them out of the process. If we use this description, we can clearly see how FMEA aligns perfectly with the new requirements in ISO 9001:2015.

For whatever reason, FMEA has now become more of a product failure analysis. Users seem to focus more on identifying the many failures that could occur if they actually produce the product. If you aren’t familiar with the APQP process, FMEA is developed during phase three of the five phases of APQP. Phase three is the process development stage, which means the process is yet to be built. So, how effective can we be if we are merely listing all the possible product failures before we have even designed the process that will produce the part or service? Product failures are simply symptoms of what we should actually be focused on when developing an FMEA. Potential process-function failures are where our focus should be when developing our FMEA. If we can eliminate the process-function failures during the process design phase, we will reduce or eliminate our risk of producing a product failure. Again, this is perfectly aligned with the new ISO 9001:2015 requirements.

Let’s look at one of the sample FMEAs we evaluated during our analysis as an example. This is a line item from an FMEA that one of our suppliers had submitted to us.

Potential failure mode: Part scratched
Potential effect(s) of failure: Customer rejects part
Severity: 5
Cause(s)/mechanism(s) of failure: Operator did not detect the scratch
Recommended actions: None (because the occurrence was rated at 5 and detections at a 4, which makes the total risk priority number = 100). Typically, organizations do not apply a risk treatment to RPN values at or under 100.

I intentionally did not insert these items into the columns of the FMEA form in order to demonstrate how it appears outside those designated boxes we were all taught to use.

If we actually try to make a sentence out of this particular risk analysis that we could give to our process designer (to design the failure out of the process), this is what it would sound like: “There is a risk level with a severity ranking of 5, which means our customers have a greater than likely chance of receiving a defect. Don’t worry about treating this risk during the process design phase because the operator is responsible for detecting the detect.”

If we have made a statement such as this, how would it be possible for our process designer to design out this particular risk so it doesn’t occur and get shipped to our customer? It isn’t very likely that this particular risk will be considered during the process design because we haven’t actually given the process designer any process functions that she can design into or out of the process.

Of course we asked the supplier why they had listed “Part scratched” under the column heading “Potential failure mode(s).” They quickly explained they have many other similar parts in full production that have experienced the same defect reported by the customer. Our next move was to observe the actual process and speak to the process owner. We asked him if he had ever experienced scratched parts. Not surprising, he replied that it was quite common. Instead of asking him to describe the potential failure mode as was listed in the FMEA (i.e., “part scratched”), we asked him to describe the Process function failure. We explained that this was the actual function within the process that would allow parts to become scratched. This is how the conservation went:

Me: “What process function failure could occur that will cause scratches on the parts?”

Process owner: “Operator not inspecting them properly.”

Me: “No, I'm not interested in trying to detect the defect just yet. What I am curious about is where in the actual process could scratches occur?”

Process owner: “Oh, well what we have found is that if you stack the parts on top of one another, they will scratch really easily.”

Me: “OK, Well, why would we need to stack the parts on top of one another?”

Process owner: “Well, we can only put 25 pieces in each box, then the operator has to move the full box out of the work cell and get an empty box. The operator has to make up the time it takes to move out the full box and move in the empty box, so just before the box is full, he will walk up the conveyer line and pick up as many parts as it takes to finish filling up the box. He then places the parts on that table over there and pulls from it to finish filling up the box.”

Me: “Is it possible the operator would stack the parts on top of one another on that table while trying to finish filling up the box?”

Process owner: “It depends on how many parts he picks up from the conveyer. The table will only hold two, so if he picks up more than two, then sure, he would probably stack them on top of each other. We tell the operator not to pick up more than two parts, though.”

With little effort we have uncovered the actual potential process function failure (i.e., potential failure mode). This is what our FMEA looks like after the actual analysis was conducted:

Potential failure mode/Potential process function failure: Operators are unable to utilize a one-piece flow to package parts
Potential effect(s) of failure/Potential effects of the process function failure:
Parts are removed and stacked on a table, which causes appearance defects such as scratches, scuffs, dents, and chips. Customer rejects
Cause(s)/mechanism(s) of failure/Root cause (why would the process function failure occur?):
One-piece flow not designed into or utilized at the process work cell.

By simply changing the FMEA column headings as described above, it drives us to actually analyze our potential process function failures that could occur. When explaining the FMEA in this manner to our suppliers, they all seem to have that “aha!” moment. We have actually asked them to revise their FMEA templates and replace the old headings with the ones underlined above. This allows them a much clearer focus on the process function failure vs. merely listing all the possible product failure modes.

Now read our sentence that we would use to describe the root cause to the process designer/builder: “There is a potential process function that could fail within this process, and the effects would cause defects such as scratches on the finished parts. The potential root cause of this function failure is the lack of a one-piece flow and balancing the line so the operator has enough time to not only pack the parts, but also to get a new box when the other box is full.”

Compared to the previous example, we can clearly see how actually addressing the potential process function failure allows us to take preventive actions on this process to avoid the defect. Identifying defects (or any other product characteristics for that matter) as the potential failure mode does nothing to address the actual process function that creates the defect.

How FMEA works for the revised standard

The revised ISO 9001:2015 standard clearly directs us to do five specific tasks. We must 1) establish our context; 2) identify our risks; 3) analyze them; 4) evaluate them; and lastly 5) treat them.

Now that we have a better understanding of FMEA by rewording several of the column headings, we can easily match these five requirements up with our FMEA. They just seem to make more sense when we look at them this way:

ISO9001:2015 requirement

FMEA column name

Revised FMEA column name


Establish the context

Process step / Requirements

Identify the actual process functions

Identifies the process functions of the process we are analyzing

Risk identification

Potential failure mode

Process function failure

Describes the actual function that could fail, not the part defect

Risk analysis

Potential effect(s) of failure

Potential effects of the process function failure

Describes what occurs when the process functions fail (i.e., our risks), and the consequence

Risk evaluation

Potential cause(s) / Mechanism(s) of failure

Root cause of the process function failure

Describes why the process function would fail

Risk treatment

Recommended actions

Preventive actions

Describes the preventive actions we will take to treat the potential risk

FMEA is not just for processes that actually build the product or service; it is also the perfect analysis tool for those supporting processes (to establish the context). Be sure to include processes in your context that also have potential risks, such as labeling the product, material handling and warehousing, inspections, hiring, and training.

I am confident that if you read through the new ISO 9001:2015 standard and then review your FMEA book from AIAG, you will see FMEA in an entirely new light. So far, Cor and I have seen great success from the suppliers we have formally trained. One particular supplier has reduced its overall defect rate by more than 75 percent.

Without a doubt, the key to a successful quality management system that is compliant to ISO 9001:2015 is the tool that has been in front of us for more than 25 years, FMEA.


About The Author

Michael Ray Fincher’s picture

Michael Ray Fincher

Michael Ray Fincher is the Value Improvement Engineer at Yamaha Motor Manufacturing Corporation of America.  Throughout the past 25 years he has been involved in developing operating systems designed to meet specific needs of organizations and to manage and operate their businesses more efficiently. Fincher’s passion is to help others solve problems by educating them on the basic tools and principles that will allow them to drive successful business systems. Fincher is the author of Problem Solving the Solution to the Puzzle (CreateSpace Independent Publishing Platform, 2010), and Achieving Operational Excellence by Building Sustainable Foundations (Slideshare, 2016).


The Old Forms Are Fine When Used Correctly

I have taught and implemented FMEAs for over 30 years.  I have applied them to well over a thousand products from a wide variety of industries.  I have seen their proper use improve the design and manufacture of a wide variety of products including molecular assays for the detection of various diseases including HIV, late stage cancer treatments, hybrid vehicles, flat screen TVs and just about every automotive component you can think of.  Standard AIAG Design and Process forms were used that included a class column.  Let me begin by saying that the forms are fine, it is what we are putting in the forms that is the problem.  If you know what goes in each column and properly calculate and use the Class Column to determine the issues you must work on instead of RPN, you will be well on your way to improving your products and processes.

The paper spends considerable time talking about an FMEA.  There is no such thing as an “FMEA”.  There are multiple types of FMEAs all with very different purposes.  Design FMEAs are used to manage risk due to the design’s current design specifications.   Improper design specifications are one of the major sources of risk that companies who design products face.

The Process FMEA is used to manage risk due to the current process.  There are many sources of risks that Process FMEAs can be used to manage.  Most Process FMEAs are done on manufacturing processes due to the demands of industry for their use.  Exposure to harm occurs in these processes when an out of spec condition such as scratches is created by the process.

Process FMEAs can be used to manage risk due to non-manufacturing processes as well.  Any time a process fails to create a desired output or creates an undesirable output, exposure to harm occurs.

Machinery FMEAs, when used correctly (99.9% are not), is an excellent to tool for managing risk due to improper manufacturing process design.  Since the focus of the Machinery FMEA is the design of a process, the majority of people create a Machinery FMEA that looks more like a Process FMEA which negates the value of the tool.

The following example is provided by the author as an improper FMEA:

Potential failure mode: Part scratched Potential effect(s) of failure: Customer rejects part Severity: 5 Cause(s)/mechanism(s) of failure: Operator did not detect the scratch Recommended actions: None (because the occurrence was rated at 5 and detections at a 4, which makes the total risk priority number = 100). Typically, organizations do not apply a risk treatment to RPN values at or under 100.

Contrary to what the article states, the problem with the example is not the ”Part Scratched” failure mode.  This is actually a legitimate failure mode assuming scratches are an out of spec condition.  The three major problems with the example is the cause listed and the fact that the author left out two critical columns of the Process FMEA.  “Operator did not detect the scratch” is not a failure cause.  There are 10 different types of root causes that all processes should be examined for.  One of those is mishandling of parts.  In the example provided by the author, operators can create scratches by stacking parts on the conveyor.    Consequently, our failure cause is “Operator stacks parts on conveyor”.   The proper definition of the root causes of process failure is the most important step of the Process FMEA process since it allows us to define the required “Prevention Controls”.  The Prevention control column describes how the failure causes (sources of incidents that lead to exposure to harm) will be prevented.  This column contains the primary risk controls for the process.

The next step is to fill out the “Prevention Controls” column.  When the Failure Cause column is properly filled out, the majority of the required Prevention Controls become obvious.  One simply must ask what control must be implemented to prevent the cause.  In the example provided, one may decide to implement procedures on product handling.  While implementing Process FMEAs as a Plant Manager for Ford Motor Company which resulted in average weekly cost savings of $144,000 after nine months of implementation, we implemented over 15,000 controls many of which were simple and cost very little money.

The last column that must be filled out that the author left out of the paper is the “Detection Controls” column.  This column is used to capture the checks that will be made to contain unacceptable process outputs or failure modes.  In a properly constructed Process FMEA your Prevention Controls often outnumber the quantity of Detection controls by a factor of 10 to 1.

The author proposes the following as a proper FMEA:

Potential failure mode/Potential process function failure: Operators are unable to utilize a one-piece flow to package parts Potential effect(s) of failure/Potential effects of the process function failure: Parts are removed and stacked on a table, which causes appearance defects such as scratches, scuffs, dents, and chips. Customer rejects Severity: 5 Cause(s)/mechanism(s) of failure/Root cause (why would the process function failure occur?): One-piece flow not designed into or utilized at the process work cell.

It is difficult to tell what kind of FMEA the author intends to do.  If one were creating a Machinery FMEA, the requirement that the “Operator must be able to utilize a one-piece flow to package parts” would be a legitimate entry for the Requirements column of the Machinery FMEA.  The failure mode and effects provided by the author would then be legitimate.  The example falls apart at the cause entry.  In a properly completed Machinery FMEA a detailed description of the equipment specified to accomplish the one-piece flow would be listed.  A Design Controls column would also be included to define the methods used to ensure that the one-piece flow could be supported.

It is also surprising the Prevention and Detection Controls column are left out of the example of a "good" FMEA provided by the author.  The Recommended Actions column is used to capture actions that will be attempted to reduce risk.  In real life, some will be work and be implmented and some will not.  This column is not intended to contain your risk prevention and mitigation controls.  That is the job of the Prevention and Detection columns.

It is imporant to know how the various FMEA types are used to manage risk.  As an example, let us look at the Process FMEA.  The Failure Mode Column of the Process FMEA is the objectionable incident that leads to exposure to harm.  The Effects Column contains a description of the harm.  The Severity Column is a measure of the level of harm.  The Failure Cause Column is the source of the objectionable incident.  The Occurrence Column is a measure of the probability of the objectionable incident and subsequent exposure to harm due to the source capture in the Failure Cause column.  The Class Column, determined from the Severity and Occurrence Columns defines the level of risk for the Process FMEA line being evaluated.  It tells you what the lines that have objectionable risk and what must be worked on.  The Prevention and Detection columns are used to capture the risk prevention and detection controls.  The Recommended Actions area is used to capture actions that will be taken in an attempt to reduce risk.  Some will be implemented and some will not.  If implemented, the associated columns of the Process FMEA must be updated.

In closing, Machinery, Design and Process FMEAs are powerful examples of the “Risk Based Thinking” required by ISO 9001:2015 when understood and implemented correctly.  New Machinery, Design and Process FMEA forms are not needed.  Knowledge on how to properly use them is. Tremendous benefits are available to you when these tools are used correclty.

If you would like to learn more about FMEAs and/or how to use FMEAs to help you comply with ISO 9001:2015 visit www.harpcosystems.com or contact me at Richard.harpster@harpcosystems.com.

Please do not miss my point

Normally, I do not respond to any criticism posted from my articles because I figure everyone has their own opinion and can draw their own conclusions to the material I put out there for my readers to use. The articles I publish are not just an off the cuff topic that are created to just fill up space. I try to share some realistic real world conditions that I have experienced (actually being at the Gemba) so that others may avoid the same pitfalls. I love to see discussions break out where many “on-the-ground” Engineers share certain aspects of their experiences and make points that we can all learn from.

I certainly DO NOT comb the internet looking for articles published by my engineering colleagues so that I can nitpick every detail in order to promote my consulting business for free.  

The example in the article of course was not in great detail and of course not all of the FMEA requirements were covered. Nor were the various types of FMEA’s as mentioned in the response by Richard. The point of the article was not to be an in-depth training manual for FMEA’s, merely a reminder that the FMEA is best used for risk assessment in the process and FROM MY EXPERIENCE (actually being at the Gemba) what I have seen the FMEA being used for. Every FMEA I have helped my suppliers with over the past 3 years has been improved by simply renaming the column headings so they flow much easier during the development. My point I realize will not be understood by everyone and that’s perfectly OK with me.

I would like to apologize to all my readers for drawing out such a comment that brings nothing to the discussion but an attempt to discredit my article and promote his own interest.

Before You Change Anything Make Sure It Is Required

Let me begin by saying that I “do not comb the internet looking for articles published by my engineering colleagues so that I can nitpick every detail in order to promote my consulting business for free”.  I have spent the last 30 years of my life optimizing FMEAs and other related tools for the purpose of improving companies product and process development systems.  Along with internal development activities, I am constantly doing reading from sources of all types to stay on top of any new advancements.  Consequently, when I received an email from Quality Digest that an article titled “Same Old Routine With FMEA: Not With ISO 9001:2015” was available, I was very interested in reading it. 

The changing of Process FMEA column headings has a significant impact on both the performance of the Process FMEA as well as other tools the Process FMEA must be integrated with in an effective Risk Based Product Lifecycle Management system.  Consequently, one must make sure the changes are needed before they are made.  The author begins his proof on why new headings are needed by providing a partial Process FMEA that is populated with improper data.  The author further complicates matters by leaving out the most important column of the Process FMEA for risk management which is the Prevention Controls column.  If one wants to prove an existing Process FMEA does not work, one should show how it fails when used correctly not how it fails when used incorrectly. 

When the author identifies the problems created by the “old FMEA” and provides his solution to the problems created by the improperly constructed Process FMEA, it becomes readily apparent if the original Process FMEA using the existing Process FMEA headings was properly populated with all columns shown, there would be no problems that needed to be solved with new headings the author is suggesting.

In closing, after 30 years in the field I have seen many attempts to fix what does not need to be fixed.  When I see these types of misinformation, I can either not say anything or attempt to educate the people who want to experience the true powers of FMEAs on how the existing FMEAs in their current form can be used effectively.  Since I want to see people experience the true powers of FMEAs I will always take exception to public documents that can negatively influence the people I want to help.  Unfortunately, some people can be offended because of the responses.

I find the author’s apology to my initial response amusing.  As someone who has written many technical papers that contain information that some people disagree with, I welcome challenges to information I am presenting.  The answering of the challenges gives me a second opportunity to educate.  I would love to see the author explain how any changes to the Process FMEA headers are needed when the Process FMEA is performed as described in my response and not as described in the paper.

One final comment.  Since the introduction of ISO 9001:2015 there have been numerous articles on how the existing FMEAs must be changed to be compliant with the standard.  This is simply not true.  If you are performing the various FMEA types correctly and they are properly integrated within your Product and Process Development System, you will have the backbone of a system which complies with all the "Risk Based Thinking" requirements of the ISO standard.

Thank you again Richard for

Thank you again Richard for your comment. I stand by my comments and the article when I say FROM MY EXPERIENCE, renaming the column headings have helped 100% of the suppliers I have worked with. Your experiences may be totally different. I too have been working with FMEA’s for many years and it is surprising to see how they have fallen to the waste side (again, from my experiences only). Seems we have a new opportunity to bring them back to the forefront with the requirements of ISO:9001:2015. Hopefully your approach may help some people use it appropriately as well. Again, from my prospective the approach I described in the article has already proven to help and is working much better than what they were doing before. You too should expect comments from post you make, especially when they attack the “author” and not the content. When you open with such negative statements to instantly try and discredit the author you are opening the door to some feedback of your own. I think you had some great points in your comment and some that I would love to talk about further. Sounds like you have the technical aspects of the FMEA down, your delivery though….. 

Intent Of Response

Contrary to what you might believe, the initial response was not intended to attack the author.  Rather than stating 'The Author states" I could have used a more politically correct "The Article states" when referring to the paper.  Maybe I just have thick skin after all the years I have been in the auto industry but I would not take offense if someone responded to an article that I have written and did so by beginning with the words "The Author states" since I was the one who wrote the article.  Since my knowledge of you is limited to the article you created, I am in no position to judge you.  It is also important to state that I would never attempt to discredit an individual in a public forum regardless of how much I knew about them.  If you believe I was attacking you personnaly, please accept my apology for that was not my intent.

My response was intended to show the weaknesses of the heading changes the article proposed which I believe would have significant negative consequences on the plant which I ran and the many companies I have worked with over the past 30 years.  One topic that I should have talked about in the response is the negative impact the heading changes you are proposing would have on the ability to link the Process FMEA to the Design FMEA and Process Control Plan which must be done.  It is critical that all core tools of a risk management process be properly linked which your propsed methodology prevents in some instances.  These linkages allow the company to perform many day to day activities that significantly reduce risk exposure in a very efficient way.

We are obviously both passionate about FMEAs and their potential.  I do not doubt that you have helped companies.  I just believe there are methods that could take them even further.