Use Cases: Preventive Maintenance Optimization

Preventive maintenance tasks often get created when there is an unplanned breakdown on a machine. These PM tasks get documented and followed up on without anyone knowing whether that task is helping to prevent that failure mode, or what is the optimal interval for the task. Maintenance hours are often wasted on PM tasks that are being performed more often than necessary, or that may not even be required at all. On the other hand, there are failures occurring that could be prevented by PM tasks that could be added or run more frequently. The desire is to run only those PMs that have an impact and only at the required frequency, but no more often than that.

In the past, it was hard to experiment to find the right interval because the data was not readily available to measure the impact. However, machine monitoring solutions capture the data necessary to analyze a before and after picture for when the PM task is created, and experiment with the PM interval to see the impact on failure rate. The next step is to identify whether to continue the task and how often it should be performed.

Who is Involved?

There are many people involved in this process. Let’s break that out into a SIPOC structure.

Suppliers:

The first set of suppliers to the process are the people in production. That team is the one responsible for capturing performance data from the process and ensuring proper downtime reasons are assigned to each unplanned failure. They can also provide anecdotal information about how the process performed prior to a shop floor data collection system being implemented.

The maintenance team itself is a supplier of information to the process. They can supply the existing list of PM tasks, the frequency, and the history of when they have been performed.

Even the machine vendors themselves can be viewed as suppliers to this process if they provide standards around PM activities for their equipment.

Process:

This process is typically performed by a combination of people from the maintenance team, as well as the continuous improvement team that may have more experience with interpreting data and running this type of analysis.

Customers:

The maintenance team is a customer in that they will be executing the updated maintenance plan. The production team would be the other primary beneficiary. Hopefully the result of this project is better functioning equipment!

Other Stakeholders:

Other stakeholders would be people that benefit from improved shop floor performance such as management and finance.

Why is it Important?

The potential of the project is significant. From a functional perspective, this should have a direct impact on maintenance hours required. It will likely decrease the number of hours spent on PM tasks, though that number can increase in situations where not enough PMs were being performed. But it should reduce the number of hours spent on reactive maintenance required due to unplanned downtime events. That is because the unplanned downtime events themselves should see a significant reduction. That reduction will then drive improvements to many KPI such as throughput, on time performance and schedule adherence.

This will also drive many financial benefits. The overall maintenance expense should decrease, but there will almost certainly be a decrease in maintenance overtime hours required when unexpected failures occur and must be immediately addressed. If throughput is increased, revenues should go up as well. If on-time performance is improved, this could also lead to a reduction in customer penalties.

Other benefits could include improvements to product quality. When machines fail unexpectedly, the parts in-process can often be damaged. In other environments such as a bakery, unplanned stops in the process can cause large portions of the in-process material needing to be scrapped. Another soft benefit is that the quality of life at the job is higher for everyone involved when unplanned downtime decreases.

Why is it Hard Today?

Optimizing the PM schedule today can be hard for many reasons. There could be a lack of understanding of how to perform the analysis. While the overall project is intuitive, the team may not have the background required to go through the details of the analysis.

Probably the biggest reason this hasn’t been done (or done well) in the past has been a lack of data. Without good information about the process downtime events and causes, it is nearly impossible to perform this optimization. With limited data, there just is no good way to measure the impact of each PM task.

Because the data hasn’t existed in the past, there has not been an emphasis from management on the optimization process. There’s often a recognition that the existing PM schedule isn’t optimal, but there’s a sense that they couldn’t do anything about it without a massive, sustained, manual data collection effort.

How Can We Do It Better?

However, the capability exists today to do this process better than in the past. The first step is a recognition that this is something that should be done on a period basis, such as once a quarter or per year.

There will likely be training or upskilling required to run this process. The teams involved may not know how to gather and interpret the data itself. They may also need training on how the optimization process should be performed.

Technology plays a key role in enabling this process. As has been mentioned many times, data is key to making this happen. A solution will be required on the shop floor to gather performance information from the machines. The solution could be an IoT system, an OEE solution, or any other type of solution that gathers the required data from the manufacturing process.

As a quick aside, when considering whether to only gather data from constraints or the whole shop floor, processes like this aren’t possible across all your machines unless data is collected from them all. It is one of the many reasons I am biased towards implementing data collection across the whole shop floor.

An AI/ML system could be greatly beneficial to executing this process. Even with the new systems in place, people probably can’t perform the analysis more often than once per quarter on a project basis. On the other hand, an AI system could continually update the PM interval based on the data coming from the shop floor. It would also eliminate the need for some of the training. It should be noted at that this time, I do not know of any vendors that provide this analysis out of the box – with or without AI.

All of this is dependent on the collection of data from the shop floor and having a stable enough network to support the data collection.

Key Data Sources

The key data sources are straightforward. The maintenance management system needs to supply the existing PM task list, along with the frequencies of the tasks and when the tasks were created. The history of when those tasks have been done in the past can also be very helpful.

The shop floor data systems will provide information about the machines. They should provide the downtime history, the failure reasons for those downtime events, as well as other performance information.

Case Study

This case study is for a fictional company, but it has its basis in projects performed over the years.

In this case, we’ve implemented an IoT system for a customer. The initial focus for the customer was on rapid identification of events on the shop floor and reacting quickly to those events. There was also an understanding that once the data collection was in place, we would identify other opportunities to use that data to drive improvements.

Once the initial use cases were up and running, we started to look at what else could be done. The customer knew that some of the PM tasks were of questionable value. We also knew for certain that some of the failure modes we were documenting were not covered by the existing PM tasks.

We performed the initial analysis in MS Excel for the first group of resources. Once we got results from that analysis, we created a template for the analysis in PowerBI that automated the grunt work of pulling the data from the different systems and running the different calculations.

The overall results were very strong. We identified that over 40% of the PM tasks that were currently being performed could either be eliminated entirely or have the frequency of the task decreased. This led to big savings in time for the maintenance team.

These savings were somewhat offset by the addition of about 15% new tasks. Some of these were brand new to cover failure modes identified that were preventable from new PMs. We also identified some existing tasks that were impactful but needed to be run more frequently. Interestingly, there were not as many tasks where the frequency needed to be increased. This is likely because without good data, the interval was set too frequently because it was perceived that it was better to perform it too often than not often enough.

These changes led to a big reduction in unplanned breakdowns of the machines. The number of downtime events dropped by 20% and the total downtime by 25% for those failure modes that were covered by PM’s. Naturally, unplanned stops for reasons such as a lack of material were unaffected.

Summary

That’s it for today!

If you have questions or would like to talk about how to apply these concepts within your company, please reach out to us at VDI.