Used at scale, AI-driven systems that continuously monitor machine health can transform industrial maintenance — but like every new technology, there are hurdles to clear before their full value can be harnessed. In part 2 of this four-part guide, we addressed the number-one challenge in every full-scale rollout: getting everyone on board. In this article, we’ll look at how to plan your condition monitoring scale-up so your systems and processes fully benefit from the new technology.
Here’s a good rule of thumb while you’re drafting your implementation plan: don’t make changes to business-as-usual any bigger than they need to be. Every time you look at how the new technology will change people’s work, first ask how you can integrate it with their existing processes and systems. Only change what’s already there when keeping it intact would work against the goals of the rollout. Now for two concrete tips on putting this rule of thumb into practice.
When you conduct a pilot, it’s easy to follow your own separate process for what you’re doing. Because you’re testing the technology, the new condition monitoring alerts are still separate from your existing ways of working. But when it comes time to implement at scale, the new alerts become part of the whole ecosystem, affecting how you generate work orders, stock parts, schedule shifts, and everything in between. You don’t want to discover too late that the system you chose will force the entire organization to use a separate dashboard and create even more administrative overhead to shuttle information between systems.
Think about other potential weak spots in scaling the pilot. How much employee time will the new tech consume at scale? Two maintenance engineers can handle all the incoming CBM alerts when you’re monitoring a hundred assets, but that setup will start showing cracks at three hundred, and you’ll burn out your engineers at a thousand. Where will the process for handling alerts intersect other processes? It will be problematic if the new CBM system tells you to replace a pump but the existing pump replacement protocol only lets you do that once every five years.
Where the new and existing procedures conflict, you’ll need a rollout champion high enough in the company to prioritize the CBM project over legacy processes and misguided incentives. That will keep you from ending up in bureaucratic scenarios where two conflicting processes block each other without anyone who can decide which one you’ll go with.
In the case of a regulatory body like Ofwat in the UK, you’ll also want to partner with other companies in your sector to open a discussion with the regulator on how they might incentivize decisions that will improve operational resilience and energy efficiency for the long term.
In the previous post in this series, you added the human element to your implementation plan. Now we’ll expand the plan again, to address the procedural side of the rollout. By the way, this is a great place to plan for local teams to drive the action: who knows their interdependencies and procedures better than they do?
- Add a section to your implementation plan that covers existing systems, operating procedures and team interdependencies. Decide how you’ll fill in the details: surveys, focus groups, interviews, and so on. Capture as complete a picture of the current state as you can. Identify relevant executive sponsors once you’ve mapped out the terrain.
- Using the scope and time frame you defined in step 2 of the first article, sketch out when each stakeholder group will integrate the new condition monitoring system(s) into their existing workflows. Will you be doing a phased rollout of the new technology? If so, include opportunities for early groups to share what worked and didn’t work with later groups.
- Using the stakeholder communication plans you started drafting in the previous round, update the sections on how they’ll play an active role based on your work from the steps above. Keep in mind any process-related concerns or frustrations you identified in the previous round — this is a great place to encourage buy-in, by specifically naming them as aspects the local group will have the freedom and authority to fix during the rollout. Remember, this is a communication plan, not a plan for how workflows will actually change. Your job here is to decide how you’ll put the local team in the driver’s seat.
How to write a strong, resilient implementation plan for condition-based maintenance at scale