Solving the Mechanical Integrity and Reliability Program Sustainability Puzzle

Introduction

Observing the development and evolution of technology in our industry over the last 40 years has been both encouraging and frustrating. Those mixed emotions were, and continue to be, the fuel for my passion for creating Inspectioneering Journal. Technologies were being misapplied and oversold, and owner-operators were spending more than necessary because they didn’t understand the total cost of ownership for a given program or how it would contribute to better decisions and a better end result. Oftentimes, these misunderstandings resulted in immense amounts of rework. Sometimes, initiatives didn’t even get off the ground, much less achieve the promised ROI.

In this article, I’d like to address sustainability of mechanical integrity initiatives. More specifically, this article considers initiatives involving integrated, systematic processes and programs like RBI, RCM, APM, and EAM programs. These programs are often complex and can be connected to, for example:

• master databases (ERPs such as Oracle and SAP)
• integrated programs to manage integrity operating window information and notices
• programs that measure and report data, such as on-stream process monitoring, laboratory results reporting (LIMS), or a CMMS

The more platforms and functionality that is integrated, the more complex the challenge can become for the right mix of products to achieve the desired results. On top of that, many of these software initiatives are considered disruptive (i.e., doing something different or in addition to what you are already doing). This means the value has to drive the investment. Is the juice worth the squeeze?

What are Your Desired Results?

So, let’s start with THE DESIRED RESULTS. Ask yourself the following questions:

• What do you want to accomplish over the next 3-5 years and beyond, as much as foreseeable?
• Do you have the right team to provide the vision and enough details to share the vision from a high level, create a credible value proposition, lay out the plan, and put it in the proper context (see my Inspectioneering article, “Without Proper Context, Your Ladder May Be Leaning Against the Wrong Building”)?
• Do you know what your desired situation is in 5 years?
• What do you wish to improve (e.g., risk management, availability, leak rates, cost optimization, improved risk profile, a better understanding of risk drivers, etc.)?
• What does “good” (I did not say excellent) look like?
• What is the probability that you will achieve it without surprises or rework?
• Do you know enough about the landscape not to “paint yourself in a corner” and set yourself up for failure (i.e., having to rework major parts of the infrastructure, such as data hierarchy, taxonomy, EAM naming conventions, codes and standards, company policies, etc.)?
• Are the interdependencies known or understood by the team, such as business analysts who should be acting on behalf of the ultimate users and beneficiaries of the program, providing input for features, functionality, workflow, and the connections with the integrated capabilities and modules and IT group?
• Do they fully appreciate the challenges, workflow, and workload of the end-users? The sooner you course correct, the better! For example, if you want to implement an EAM that encompasses and is tied to CMMS, ERP, IDMS, and RBI, do they speak the appropriate language, make effective hand-offs, close loops, provide KPIs, etc., as desired to achieve your goals?