Asset Lifecycle Management using a PLM system

Although I am still active most of my time in ‘classical’ PLM, some of the projects I am involved with also deal with Asset Lifecycle Management. In general PLM focuses on a product development process, starting from a conceptual phase, going through planning, development and production. The PLM system serves as a collaboration and information backbone for all product IP (Intellectual Property). One of the main capabilities a PLM system provides is a ‘single version of the truth’.

And it is this capability, which makes a PLM system an excellent choice for Asset Lifecycle Management

Who practices Asset Lifecycle Management ?

Asset Lifecycle Management can be found at any location, where a company is maintaining a process – we call these companies Owners/ Operators. Best known industry for Asset Lifecycle Management is the Process & Power industry, where a company produces oil, energy or chemicals. However the same concept is also valid for water companies (water distribution process), food processing and infrastructure companies (railways, airports, roads)

All these companies have in common that they support a certain process and the challenge is, while being in operation, to optimize the process. During operation, maintenance and improvement activities should be as little as disruptive as possible.

A maintenance stop is very costly for Owner/Operators. Imagine a plant not producing fuel for two weeks (millions of liters) or a nuclear reactor not producing electricity for a month (millions of kilowatts) – no income. And no maintenance will lead to unexpected problems and in the worse case, disasters. So it is also about balancing these activities.

Let’s look at a definition of Asset Lifecycle Management

Asset Lifecycle Management is a balanced and active management of assets over the lifecycle, coupled with business objectives.

Simply said it translates into an approach, where based on business objectives (process stability, safety, margin) a company tries to optimize the usage of their assets (a reactor, a pump, a rail track, a road) through their individual lifecycles. This means perform preventive maintenance; renovate a part of the process and perform more parallel activities with a focus on improving the lifecycle of the process

So why not use a MRO system?

An MRO (Maintenance, Repair & Overhaul) system can be compared with an ERP system for manufacturing companies. The MRO system manages and schedules activities and resources on the plant, keeping track of maintenance activities done on inventory. But can it serve as the system providing the single version of the truth for all plant information? No!

So why not use an ERP system?

An ERP system is mostly used by owner/operators to control all financial transactions (contracts, purchasing, suppliers, projects/resources accounting). Some ERP vendors provide MRO functionality in a single system; still can this system provide the single version of truth for all plant information? Again I am sure it is not the case.

So why not use a document management system?

As most of the process information is stored in various types of documents, is seems to be appropriate to store all information in a document management system. And actually this is what owner/operators try to do, however they maintain inside their company different document management systems (paper archives, office documents in a specific system, engineering documents in another system, etc, etc). Each of the systems can provide a single version of the truth for specific content, however there is a consolidated single entry point for all asset data. Often the documents also do not reflect the status of an asset. Is the asset running in, is it active, is it demolished?

The tag number does not show it, and changing the status of an asset forces people to go through the various document systems to change the status there. An inefficient and costly procedure, not reliable and often not done.

So why not an integrated plant engineering system?

Engineering plant software is designed to support the design collaboration and is mostly used by EPC contractors. These engineering companies are hired by the owner/operator to design and construct the plant or make major modifications of the plant. EPC contractors need to work as efficient as possible (to get the job), which means for them work as intelligent as possible in an integrated manner with tag numbers, P&IDs, 3D Equipment, Piping, ISOs. This intelligence leads to an application specific format and infrastructure.

During the hand-over of the plant or modification, this intelligence disappears as the owner/operator does not use the engineering plant software. They do not want to be dependent on a single software provider or version of the data. As data has to live for many years, sometimes 30 years or more, application specific data is hard to maintain. So as part of the hand-over data will be provided in neutral formats, worst case paper, but often in PDFs, TIFFs or other publishing format, losing all the intelligence.

There is an intelligent, neutral format based on ISO 15926. This requires an investment from the EPC contractor and an investment from the owner/operator to manage all information in this format. For complex and long-lasting environments, like a nuclear plant, this approach surely pays off; however what you see is that on both sides (EPC and Owner/Operator) they try to minimize the costs on data handling/conversion. This leads in the long term to much more labor time internal at the owner/operator to manage and assure the data is accurate. But these costs somehow come later and are more hidden. And the question remains: can this system serve as the single version of truth for all plant information? No, plant engineering systems are too application specific

In addition, plant engineering software environments are not targeted to work integrated in an owner/operator environment, managing parallel projects and resources, quality processes and inventory statuses related to a certain asset and project.

So why not use a project management software system?

As in a plant many projects can run in parallel, it happens that they run on the same assets or locations in the plant. For engineers and maintenance it is important to have visibility on which projects have impact on each other. Project management software is not targeted to make data visible related to a collection of assets or locations. No, project management software can not be the system to serve as the single version of truth for all plant information.

So either we give up for looking a single version of the truth and pay the price for multiple software systems to maintain in the company and take the extra efforts for configuration management for granted, or we look at PLM ?

The PLM based solution

In the past 15 years I have done several projects with ENOVIA and projects where Asset Lifecycle Management was done with ENOVIA. For sure, other flexible PLM systems can do the same, as the solution lies in an adapted data model for ALM.

This picture shows what a PLM system can do:

It can provide all related information (documents, inventory, locations, and projects) to an asset with one click from within single system. In addition it can also give the actual status of the asset. Assets are often identified by tag numbers, and the lifecycle of an asset can be managed by default in a PLM system, combined with Asset Change processes.

Best Practices coming from the PLM world can be used here too. The major challenge for PLM vendors is to reduce the complexity for data handling, as ALM users will not be engineers experienced to complex CAD environments. They are information workers, who need with a short learning curve, direct access to the data they require (and they should be sure the data is reliable)

Note: the PLM system will need to interface with the MRO and ERP system. Like in the classical PLM concept, MRO and ERP are the transactional systems, controlling the day to day activities, where the PLM system provides the accurate plant information (IP) required for an activity.

Also the PLM system will manage the non-standard activities through projects, change processes and will rely on accurate information from ERP.

The major benefits reported from implementations based on a PLM system are:

• Reduced down-time for the plant, due to better planning and accurate information when preparing a maintenance stop. Less surprises with unforeseen delays of production.
• More reliable and less effort to be complaint to safety, health, environment and governmental regulations as all information is available in a single, controlled and traceable environment
• Lower cost of ownership for ALM. Instead of maintaining various silos of information and provide access to certain users, a single system with a common interface is available for most of the users.

Conclusion: Owner/Operators should look into the benefits a PLM system can bring for them. Interesting the benefits are not based on the integration of product development, but on providing accurate information from different entry points for different roles

 I am curious to learn who has seen a similar approach – feel free to comment