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.
Leave a Reply