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 Robert (Bob) J. Latino Leave a Comment

So how Should I use the SAP-PM Breakdown Indicator?

So how Should I use the SAP-PM Breakdown Indicator?

Guest post by Ken Latino.

There are many opinions about the use of the breakdown flag in SAP-PM. I would like to offer my opinion on this debate. First, I do not like the term “breakdown”. With a name like breakdown, nobody will want to check the box! No one likes to admit that a something has failed or is broken. I wish the field were named “reliability event” to take away this negative connotation.  I will discuss this in more detail later.

Before I move any further, I would like to talk a little bit about how the breakdown field is used in SAP-PM. If the box is checked than it assumes that a “failure event” has occurred and the information is used in the internal maintenance and reliability reporting within SAP-PM (e.g. MTBF, Availability, etc.). The problem with this is that the use of the field is somewhat subjective. For example, what is a failure to one person is not a failure to someone else. Here in lies the problem. A clear and non-subjective definition of failure must be documented and communicated to everyone involved when documenting maintenance history. Otherwise, the use of the breakdown indicator will be insufficient for reliability analysis purposes.

So, what definition can be used to ensure that there is no room for misinterpretation? Well, there are several definitions of failure floating around industry. The definition that I like the most is the one provided in the ISO-14224 standard. 

“The termination or the degradation of the ability of an item to perform its required function(s). A required function is defined as the item’s capability of providing its intended function. Note that a failure could be either complete loss of function, function degradation below an acceptable limit, or an imperfection in the state or condition of an item (incipient failure) that is likely to result in a functional failure if not being corrected.”

Although I like this definition and I think it encompasses all needed events, it is still somewhat subjective. People can interpret it in different ways and therefore our maintenance history will not be completely accurate. As I stated before, I do not like the term “failure”. I think it has a negative connotation. Instead of focusing on the negative, we should be more focused on documenting events that affect the performance of our plant assets. I prefer the term “reliability event”. This takes the stigma away from the word failure and allows us to focus on analyzing events that effect overall plant reliability. Let us get back to the definition of a “reliability event”. I believe it is easier and less confusing to define a “reliability event” in the following way:

“Any event that requires the repair or replacement of a component”

This definition will make it easy for technicians to determine if a reliability event has occurred. If you replaced a component or had to repair it to restore its intended function, then a reliability event has taken place. It is as simple as that! No confusion or misinterpretation.

Let consider a couple of examples. If a technician goes out to a centrifugal pump and replaces packing that was leaking, then that would constitute a reliability event. If an instrument technician must calibrate an instrument that has drifted, then a reliability event has taken place. As you can see, this is a much less subjective way to determine if an event should be documented and used for reliability analysis purposes. 

You might say to yourself, what if an inspection took place, is that not a reliability event. My definition of reliability event is whether that event changed the performance of the component in any way. An inspection that did not require any change to the component did not change the component’s performance. Therefore, it would not be used in a reliability analysis. It becomes a reliability event when the inspection identifies a potential problem that was subsequently addressed by a repair or replacement of a component. 

Let’s get back to the discussion of the breakdown box in SAP-PM. When a technician determines that a component has been repaired or replaced, the breakdown box should be checked. They would also update the Malfunction Start and End Date as well as creating items in the notification to document the applicable Object parts, Damage codes, Cause codes and Activity codes. 

This approach to the breakdown indicator will ensure that it is used properly, and your reliability analysts will not have to guess which events should and should not be used in their reliability analysis work. 

In summary, if the breakdown indicator is going to be useful for reliability analysis it must be used in a standardize manner. Having complex or vague definitions of when to use the indicator will only cause confusion and inconsistent use of the indicator. I recommend a more practical definition for the use of the indicator that will help ensure its correct use and thus providing better quality information for making asset performance decisions.

Filed Under: Articles, on Systems Thinking, The RCA

« Cheap Way To High Pumping Circuit Availability
OSHA Chemical NEP »

Leave a Reply Cancel reply

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

logo for The RCA article series image of BobArticle by Robert (Bob) J. Latino
CEO of Reliability Center, Inc.

in the The RCA article 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 Posts

  • What is the Difference Between Quality Assurance and Quality Control?
  • Covariance of the Kaplan-Meier Estimators?
  • Use Of RFID In Process Safety: Track Hazardous Chemicals And Track Personnel
  • How to Reduce Maintenance Cost The Right Way
  • Significance Over Success. Innovation Over Change. Anticipation Over Agility

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