Hello everyone, I work as a reliability engineer and I have a query regarding PdM & PM findings in our company's SAP system. We classify maintenance requests as M1 & M2, with M2 being for repairing assets in case of an unreliability event like a trip, failure, or asset not functioning as intended. All M2 requests must be investigated. My question is: if a problem is identified during PM that requires fixing, is this considered an unreliability event? In my opinion, any corrective action resulting from PM or PdM should be seen as proactive work and not classified as an unreliability event, excluding it from MTBF calculations. Can you please provide guidance on this matter?
Determining the expected life of assets is a crucial aspect of asset management. MTBF, which stands for Mean Time Between Failures, is specifically designed for non-repairable assets to calculate their expected lifespan and ensure overall reliability across the asset population. This calculation can be applied at the component level, focusing on a single failure mode of a specific component type, such as pump seals. By analyzing factors like installation practices, the medium being pumped, and duty cycle, MTBF provides insight into the life expectancy of assets under current operating conditions. On the other hand, MTTR, or Mean Time To Repair, is tailored for repairable assets that can be restored to their base condition. When using MTTR, it is important to include all corrective interventions, even those identified before catastrophic failure, to determine the frequency of asset maintenance beyond standard inspections. Proactive inspections play a key role in identifying asset issues, with SAP PM offering a task type to differentiate work identified during PM or condition monitoring orders. This helps evaluate the effectiveness of the maintenance program, with a recommended ratio of 4 or 5:1 corrective tasks for every set of PMs executed. When addressing the need for investigative actions, it is essential to consider the recurring nature of events and adjust criteria accordingly. Not all issues may warrant in-depth investigations, especially if they involve expected wear components that are reaching the end of their life expectancy. Understanding the context of asset management, risk tolerance, and trigger criteria is vital in determining the appropriate course of action to optimize asset reliability and performance.
George, I appreciate your detailed response. I face challenges with the corporate maintenance department regarding the investigation of reported M2 events. Let me provide some context. The operations team categorizes all issues, big or small, as unreliability events (M2) to streamline material orders. However, the SAP system automatically flags M2 events as failures and calculates MTBF. Simultaneously, reliability requests are initiated to investigate these unreliability events using the 5-whys approach through the FRACAS system. This process has resulted in an overwhelming 500-600 notifications in just 6 months, many of which are minor issues like "small oil leak" or "fix pump packing." To complicate matters, the corporate maintenance department has set a KPI target of investigating 85% of these notifications to remain compliant. These notifications fall into different categories: IA for issues found during PM, 1B for those discovered during PdM, and 1C for unplanned failures, drips, or defects. I propose focusing on investigating only the 1C category, while the others should not be classified as unreliability events. My suggested procedure is to issue a minor maintenance ticket for any incidents to determine if they are genuine failures or minor issues that can be easily resolved within a limited budget. Only escalate to M2 with the 1C category if further investigation is warranted. Additionally, incidents discovered during PM or PdM should not be classified as failures, as they are part of routine maintenance. I find it unrealistic for a company to investigate 500-600 failures in 6 months. What are your thoughts on this matter?
Managing a high volume of issues can be overwhelming, even when using a simple technique like the 5 Whys. It is important to establish clear criteria for triggering a Root Cause Analysis (RCA), which may evolve as you address larger and more critical events. By reviewing the 500-600 collected issues for commonalities, you can narrow them down to a more manageable number, such as 50. Develop criteria to only investigate these 50 issues, presenting this approach to management for prioritization. As you address and resolve these issues, gradually adjust the criteria to include slightly smaller incidents. A strong Root Cause Analysis process should result in fewer than 50 issues on the list over time. Once this occurs, consider revising the criteria further. The goal is to maintain a manageable list of investigations while making progress towards improvement.
Before diving into Predictive Maintenance (PdM) or Preventive Maintenance (PM), it's essential to consider the industry you're working in, such as oil & gas or petrochemical. I am well-versed in both of these industries, so I can confidently say that if you implement PdM, PM may not be necessary. This not only helps save on PM costs, but also ensures that all PdM findings are addressed promptly. By gradually reducing our PM schedule, our plant now relies heavily on PdM. For example, if a small oil leak is detected during PdM, we schedule a repair date alongside a major overhaul, which is determined by the results of PdM analysis.
Hello! Your approach to classifying PM and PdM findings certainly makes sense. In my experience, preemptive actions from PMs should not be considered unreliability events since they’re intended to prevent such events from happening in the first place. Effectively, these actions aim to fortify the reliability of your equipment. The key is to clearly differentiate between corrective actions that correct an existing failure (which would contribute to the MTBF) and those that prevent a future failure. By doing so, you can steer towards more accurate reliability metrics. It's a nuanced area, so maintaining clear definitions in your SAP system will be crucial. I hope this helps!
I agree with your perspective. Issues identified during preventive maintenance (PM) or predictive maintenance (PdM) are proactive endeavours, taken to eliminate the likelihood of unreliability events or to drastically reduce such instances. Classifying them as M2 or as unreliability events may distort your MTBF data, since these are not instances where an asset has failed during operation. However, it might be beneficial to keep track of PM and PdM findings separately, as a way to measure the efficacy of these planned maintenance strategies. Your precise treatment, though, may pivot on the specifics of your operational context and the conventions of your industry.
I agree with your viewpoint that corrective actions stemming from PM or PdM should be considered proactive work. An unreliability event in my understanding refers to an unexpected asset failure or interruption in operation, causing a reactive situation. When potential issues are found during PMs or PdMs, they're identified before becoming a larger problem, thereby preventing an unexpected event. So, I would categorize them differently and exclude these from MTBF calculations, maintaining the distinction between proactive maintenance and reactive repairs.
I understand your perspective and largely agree with it. In my experience, problems identified during PM and PdM are more indicative of successful proactive maintenance rather than actual unreliability events. The aim of these practices is primarily to catch and correct issues before they lead to failure. Labeling them as unreliability events could potentially skew your MTBF calculations, creating an inaccurate portrayal of your asset reliability. However, it's crucial to have clear definitions in place for what counts as an 'unreliability event'. This is something that might need revisiting within your company's maintenance protocol.
Great question! I agree that distinguishing between proactive maintenance and actual failures is crucial for accurate metrics. Typically, if an issue arises during PM or PdM that requires corrective action, it doesn’t fall under the same category as an unreliability event, since you’re addressing potential problems before they escalate. However, the interpretation can vary by organization. It might help to discuss this with your team to see if there’s a consensus about how to define these events within your SAP system. Clear definitions can really improve overall maintenance strategy and reporting!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: Maintenance requests are classified as M1 and M2, with M2 being for repairing assets in case of unreliability events such as trips, failures, or assets not functioning as intended.
Answer: Answer: The opinion expressed is that any corrective action resulting from PM or Predictive Maintenance (PdM) should be viewed as proactive work and not classified as an unreliability event, hence excluding it from Mean Time Between Failures (MTBF) calculations.
Answer: Answer: Yes, all M2 requests for repairing assets in case of unreliability events like trips, failures, or assets not functioning as intended must be investigated.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.