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
    • 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
    • Asset Reliability @ Work
  • 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
      • 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
    • 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?
      • 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
    • 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 Fred Schenkelberg Leave a Comment

When to Take Action on Field Failure Data?

When to Take Action on Field Failure Data?

Not much. You need just enough field failure data to identify the root cause and determine if and how to resolve the problem.

Field data will accumulate even if your program works diligently to prevent failures.

The actions taken before the reported failure will frame when you need to take action.

Gathering failure data and evaluating the trigger points for action is a reactive approach. This approach means you will only respond to problems.

You will also likely not spot the important emerging issues before they become significant problems.

The meaning of field failures

A failure in your customer’s hands is your product not meeting your customer’s expectations.

Not all field failures result in a call, return, or complaint. Therefore, the failures that you do learn about become critical sources of information about how well your product is or is not meeting expectations.

A field failure is what the customer calls a field failure.

You do not have to reproduce the failure, nor confirm it was due to negligence or abusive use to reclassify the failure to something else.

If a failure costs you time or money, it is a bit of information you cannot ignore.

A failure in your customer’s eyes is not limited to hardware or software elements of the system.

I once received a product return because the box said it was 100 meters in length, and it was closer to 103 meters. The length should match the labeled length, else it is a failure according to this customer.

A failure could be a problem with the advertising, ordering process, or assembly instructions.

A failure that is hardware or software related may be harder to remedy, yet any failure is a symptom of a process failure in your organization.

Every failure contains information

A failure provides an immense amount of information if you look. Each failure may include:

  • Symptoms noticed by customer (what they deem a failure)
  • Environment and use conditions surrounding the product
  • Functional and duration expectations
  • Consequences of failure (safety, collateral damage, loss of function, etc.)
  • Time of failure (along with manufacture or installation date)
  • Root cause of failure
  • Condition of elements that have not failed
  • And, more

Beyond tracking time on customer service calls or cost of repairs, track the essential information you need to understand the how, why, and when of each failure.

Finally, this information is valuable, so make it easy for your customers and your organization to gather and report.

It is important to remedy the issue quickly with your customer. It is vital you have the information to resolve the current problem and prevent future issues.

Economics of root cause analysis

Not addressing a field failure not only allows ongoing warranty claims, but it also erodes your brand loyalty and market share.

Not addressing the right true cause(s) of a failure wastes design and operations resources that may exacerbate the actual problem.

Using the component switch and check approach may find the damaged component. It may or may not lead to a root cause of the failure. Components can fail as they are the hero or victim of a fault elsewhere in the product.

Sending the identified part to a vendor may lead to a prompt and efficient solution. It also may lead to an extended time of little information and no resolution. Instead, use an internal or a contracted failure analysis laboratory.

Sure it will cost a bit, yet in short order, you will have a clearer root cause understanding, then you can move to effectively solve the problem.

Class defect versus isolated anomaly

When faced with a unique field failure, or even just the first (or only) reported issue, do you spring to action with a full root cause analysis and line stoppage till it is sorted out?

Most of you would not do this for a single reported failure.

If the failure caused a death, you would immediately investigate in detail. Hopefully, this is a very rare event with your product.

If the failure was from an important customer and they demanded an investigation, you would start immediately.

Addressing the problem may be a business decision and not motivated by a desire to improve your product.

Once you have compelling information that a significant portion of fielded products will fail, or you experience an increased rate of returns, you likely will take action. This may be too little information too late to thwart the impact of the class defect.

Starting your response to field failures well before shipping the first product can help.

During the design and development, you identify reliability risks, you find and resolve problems, and you also identify and do not solve problems.

The issues you resolved provides a database of failures that you know fairly well, and if they appear even once in field failure data, that should be a surprise requirement corrective action. Just one failure of a known “solved” issue is a cause for alarm.

Think about it, you identified an issue and chose to spend resources to solve the issue.

The failure provides evidence the issue was not solved. Something went wrong and the risks to product performance, warranty costs, etc. now are all back on the table.

In some cases, we can only mitigate or ameliorate an issue to reduce it’s frequency or time to failure.

Did the failure arrive as expected after the expected duration given the conditions? If it is early — again even just one failure — means something went wrong with the process to solve the problem.

Finally, some problems have not been seen before. Customers are creative that way.

Given the work to understand and solve as many issues during the development phases, a new type of failure will require root causes analysis. Even on just the first one reported.

You may decide not to resolve the issue with a design or process change, as you determine the failure will be an infrequent source of failures.

Do not base your actions on opinion, rather on the root causes analysis and good reliability engineering work.

How much failure data do you need?

Just one field failure is all you need to take action. You should take action given just one field failure.

Waiting to confirm that cracked capacitors due to board bending will cause 5% or more units to failure, may require you to wait till 5% or more fail. Instead, with the first cracked capacitor, you can identify the source of the board bending and stop it.

Immediately reduce the chance for capacitors to crack.

You still need to deal with the existing products that are at risk of failure.

If the root cause is not identified and solved early, you continue to produce systems with some fraction including defects leading to failure. Working to solve the root cause of the initial failure may lead to short and long-term improvements to your process to create reliable products.

Just one field failure is all you need to get started and make a difference.

How do you know when to take action? Add a comment and share your best practices.


Related:

Failure Analysis: The Key to Learning from Failure (article)

Field Data and Reliability (article)

Field Data Analysis First Look (article)

 

Filed Under: Articles, Musings on Reliability and Maintenance Topics, on Product Reliability

« Improving Part Quality
Building Resilience into Your Supply Chain »

Leave a Reply Cancel reply

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

Article by Fred Schenkelberg
in the Musings series

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 Articles

  • Risk Prioritization in FMEA – a Summary
  • What Are Best Practices for Facilitating Qualitative Assessments?
  • So, What’s Still Wrong with Maintenance
  • Foundation of Great Project Outcomes – Structures
  • What is the Difference Between Quality Assurance and Quality Control?

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

This site uses cookies to give you a better experience, analyze site traffic, and gain insight to products or offers that may interest you. By continuing, you consent to the use of cookies. Learn how we use cookies, how they work, and how to set your browser preferences by reading our Cookies Policy.