Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Way of the Quality Warrior
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • Reliability Engineering for Heavy Industry
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Carl S. Carlson Leave a Comment

FMEA Q and A – Managing System Changes

FMEA Q and A – Managing System Changes

FMEA Q and A

In this Q and A article, a reader asks an interesting question about whether or not to update a System FMEA, when making subsequent changes to lower-level items. This is an excellent question, and shows the reader has good insight into the application of FMEA.

“Judge a man by his questions, not his answers.”
Voltaire

Reader’s Question

Can you please help me in understanding System FMEA with respect to the following questions?

I understand that for new product programs or new application of existing design, we perform System FMEA before the design gets frozen. However, this is not best followed for Continuous Improvement changes or small design changes. In those cases, sometimes Design FMEA gets addressed, but essentially may not address system issues. Here consideration is that, those changes may affect system functionality. Example is coolant composition change, flow pressure change for pump, filter element change, etc.  Is there any objective evaluation criteria when to do System FMEA? How should this issue be addressed when evaluating small design changes, for System FMEA may require more resources and may not be feasible?

Consider the following hypothetical proposed changes:

1. Changing oil filter element material
2. Coolant composition change
3. Oil line O-ring groove depth dimension increase
4. Proprietary supplier of pump has changed some design parameters
5. Supplier suggested some changes in torque of seat mounting positions

Above scenarios are for making my query clear. Here my real concern is shall I perform System FMEA with all these changes proposed, as there may be some impact on other functional systems of vehicle? Or do you suggest some objective evaluation, so that it should give me some rating or decision on performing of System FMEA for each design change proposed. There should not be any confusion when to perform Design FMEA or System FMEA. What are your recommendations to handle these kinds of situations?

Answer to Reader’s Question

There are two ways that changes to product programs can be managed. Both will be explained below.

The first way to manage system changes is by updating the System FMEA and performing or updating any needed Design FMEAs. For new product programs, a System FMEA should be done as soon as system concept is determined, and completed (as you note) before system design freeze. The System FMEA can be subsequently updated when there are changes to the system configuration, as you describe in your question above. The System FMEA update should assess how changes to system configuration or components impact the system itself, as well as the interfaces between subsystems and/or components, and recommend actions to reduce risk due to the changes. The update to the System FMEA is not a new System FMEA, but merely a review of the current System FMEA to make needed adjustments. Your question on when to update a System FMEA can be answered as follows: when there are changes to the system configuration or componentry that impact the operation of the system itself, or impact the interfaces between subsystem and/or components within the system, it is a good idea to update the System FMEA. What sometimes seem to be minor changes to components or interfaces can cause significant system problems. In addition to the System FMEA update, individual Design FMEAs can be done (or updated) on the subsystems or components that have been changed. Not all changes justify a Design FMEA. Preliminary risk assessment can help identify which changes require Design FMEAs, and is fully covered in chapter 4 of my book.

The second way to manage system changes is through the use of Change Point Analysis and Design Review Based on Failure Mode (DRBFM). This presupposes that there is a properly done System FMEA to begin with. Here’s an excerpt from the book, which references an excellent presentation by Lisa Allen at the 2008 Applied Reliability Symposium.

A DRBFM project always builds from the success of a Good Design. Once the Good Design is established, the next step in a DRBFM project is called “Change Point Analysis.” It begins with the baseline design and focuses on the specific changes to the design. It is the initial step in Good Discussion. The main idea is to begin with a robust design and to fully understand and document all of the change points to the baseline design. Change points can include changes in design, manufacturing, supplier, supplier design or process, usage environment, interfaces, specifications, performance requirements, or any other changes.

Both Change Point Analysis and DRBFM are covered in chapter 13 of my book.

Next Article

Why do you think FMEA procedure requires effects to be taken to the system or end user? Why not describe the consequence only at the local level. If a bolt in a complex system fails, the parts that the bolt was clamping together may come apart. Isn’t that enough? The next article covers essential information about the effects of failure, along with examples and application tips.

Filed Under: Articles, Inside FMEA, on Tools & Techniques

About Carl S. Carlson

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines, supporting over one hundred clients from a wide cross-section of industries. He has 35 years of experience in reliability testing, engineering, and management positions, including senior consultant with ReliaSoft Corporation, and senior manager for the Advanced Reliability Group at General Motors.

« Plant the Seeds for Tomorrow: Implementing a CMMS
Considerations and Pitfalls when Designing ALT »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Carl Carlson
in the Inside FMEA series

[popup type="" link_text="Logo Info" ]

Information about FMEA Icon

Inside FMEA can be visually represented by a large tree, with roots, a solid trunk, branches, and leaves.

- The roots of the tree represent the philosophy and guiding principles for effective FMEAs.
- The solid trunk of the tree represents the fundamentals for all FMEAs.
- The branches represent the various FMEA applications.
- The leaves represent the valuable outcomes of FMEAs.
- This is intended to convey that each of the various FMEA applications have the same fundamentals and philosophical roots.

 

For example, the roots of the tree can represent following philosophy and guiding principles for effective FMEAs, such as:

1. Correct procedure         2. Lessons learned
3. Trained team                 4. Focus on prevention
5. Integrated with DFR    6. Skilled facilitation
7. Management support

The tree trunk represents the fundamentals of FMEA. All types of FMEA share common fundamentals, and these are essential to successful FMEA applications.

The tree branches can include the different types of FMEAs, including:

1. System FMEA         2. Design FMEA
3. Process FMEA        4. DRBFM
5. Hazard Analysis     6. RCM or Maintenance FMEA
7. Software FMEA      8. Other types of FMEA

The leaves of the tree branches represent individual FMEA projects, with a wide variety of FMEA scopes and results. [/popup]

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • test
  • test
  • test
  • Your Most Important Business Equation
  • Your Suppliers Can Be a Risk to Your Project

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy