So how should I use the SAP-PM breakdown indicator?
Written by:Ken Latino, CMRP
Practical Reliability Group

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 of all, 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 was 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 a number of 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’s 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 a mechanical seal that was leaking, then that would constitute a reliability event.  If an instrument technician has to 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 must be addressed by a repair or replacement of a component.

By recording our reliability events in this way, we can more easily know the operating life of our components and use that information to perform reliability analysis (e.g. trending, reliability distributions, etc.).  Now, you might say that we often do opportunistic maintenance where we change parts that are not defective.  We do this when we the opportunity presents itself.  For example, when a pump is down for a seal repair we might go ahead and change a bearing since the pump was down anyway.  We might do this even if the bearing is in good working order.  This is still a reliability event since we renewed the life of that bearing.  We would simply add another item to the notification showing that the bearing (object part) was replaced and the Damage field could be set to “No Damage Found”.  This would allow the Reliability Engineer to identify that a replacement had taken place that renewed the life of the component but should be censored or suspended in the reliability distribution analysis. 

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 they should check the breakdown box.  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.