Cost vs Benefit of Inspection with Dane Boers

Welcome Dane back to the podcast. We last talked about asset modelling and factors that influence those assets. Today we will talk about optimising strategies; how we determine cost vs benefit of strategies. But first, give a brief introduction of yourself and Modla.

Modla is an asset knowledge and analytic platform. The vision is to capture subject matter expertise and knowledge around an asset and business processes. It then combines that with data for continuous improvement. We have worked in the utility industry; particularly water and electricity.

You were a reliability engineer, right?

Yes. I started out in mining and transitioned to reliability and asset management. I was interested in the combination of engineering principles and the business side in reliability.

 

A lot of organisations are looking to optimise inspections to ensure the benefits are worth the costs. Is this something they should be concerned about?

A recommended approach would be to start from ground zero; activities such as inspections and condition monitoring are inherently information gathering as they do not interfere with the asset’s operation. The key is to determine the information you are looking for and the expected value it should add.

This determination will be affected by the monitoring frequency, operation factors such as timing, and detection probability.  You need to prove that the task will add value before performing it.

I do not recommend adding default tasks out of perhaps an OEM manual to the system without determining its value.

 

You can’t just borrow a task in an FMEA from another organisation because the operational contexts vary.

The consequences of it failing are going to be different. However, it is also dependent on the business maturity. Sometimes an organisation lacks the capability to do a detailed analysis of expected outcomes and so copy pasting from another is an approach.

Although, it is risky to blindly trust it.

 

How do we determine the probability of finding a defect to establish inspection frequency?

Both inspecting at a high frequency and spacing out the intervals can yield the same results because failure modes happen when they happen. The probability of finding a defect is almost 100% for obvious defects such as corrosion. It gets more complex when technologies that distance the operator from the underlying defect need to be analysed. At such a point, you might need to ballpark everything and adjust the frequency based on your operational context to improve on it.

 

We look to understand how a failure occurred in between our inspections without detection. For instance, changes in vibration indicate a misalignment that wasn’t picked during inspection or failure to carry out lubrication by the operator. How do we isolate such events to prevent them from skewing the data we collect on defect detection?

You have to use all the different tools together i.e combine SMEs and data analysis to confirm or deny hypotheses.  None in isolation.

 

Lessons from machine learning are clear that you cannot just let statisticians build models independently from SMEs. Also you cannot have SMEs isolated from staticians. They need to be interdependent.

Even in failure analysis, you need to confirm whether the data you are seeing makes sense. You need the technical side to understand what is happening in the real world.

 

But you need data sets to make a business case for the changes you need to make.

Management is using data-driven decision making but it is important to include the SMEs in the justification of the changes. The justification given by an SME is as equally important if not more valid than the data.. This is because the data has issues, assumptions, and non adjusted parameters.

 

When optimising maintenance tasks we should use liable analysis based on a single failure mode and not mixed failure mode.

The condition monitoring techniques that you might use may not pick up those multiple failure modes and this complicates the justification.

To justify an inspection, look at what would happen if it is not done. Compare that with the suggested inspection intervals, probability of detection of failure modes then link them to the failure modes.

Definitely, interventions will be needed and these need to be planned in terms of overall cost. Compare all these activities to absence of the inspection. The difference yields the value added.

 

The cost is built up from labour rates, supplies, periods of technology use. To link these, should they have a list of failure modes?

The more you understand the assets and its failure modes the more accurate your answer will be. But if you do not have the failure level information you can use the estimates. Let the SME estimate the costs and benefits of doing or not doing the inspections.

The analysis does not need to go down to details; it can be basic as long as the logic is sound and documented then improve on it.

 

The key is to learn, do an RCA and find out why the inspections did not catch the failure modes or were they just random.

When critical assets fail and an RCA is done, there are failure detection probabilities that need to be picked during the exercise. There is ofcourse a tradeoff between overinspection and lack thereof. However, do not be quick to write off your logic because it did not detect multiple failures. Instead, work on improving the logic.

 

Eruditio Links:

• Eruditio
• HP Reliability
• James Kovacevic’s LinkedIn
• Reliability Report

Dane Boers Links:

• Dane Boers Linkedin
• Modla Linkedin
• Modla – Collaboration and Asset Analytics
• Past episodes with Dane Boers

Download RSS iTunesStitcher

Rooted In Reliability podcast is a proud member of Reliability.fm network. We encourage you to please rate and review this podcast on iTunes and Stitcher. It ensures the podcast stays relevant and is easy to find by like-minded professionals. It is only with your ratings and reviews that the Rooted In Reliability podcast can continue to grow. Thank you for providing the small but critical support for the Rooted In Reliability podcast!