You are currently browsing the category archive for the ‘Tag numbering’ category.
The problem with a TLA is that there is a limited number of combinations that make sense. And even once you have found the right meaning for a TLA, like PLM you discover so many different interpretations.
For PLM I wrote about this in my post PLM misconceptions –: PLM = PLM ?
I can imagine an (un)certain person, who wants to learn about PLM, might get confused (and should be – if you take it too serious).
At the end your company’s goal should be how to drive innovation, increase profitability and competiveness and not about how it is labeled.
As a frequent reader of my blog, you might have noticed I wrote sometimes about ALM and here a similar confusion might exist as there are three ALMs that might be considered in the context I am blogging.
Therefore this post to clarify which ALM I am dedicated to.
So first I start with the other ALMs:
ALM = Application Lifecycle Management
This is an upcoming discipline in the scope of PLM due to the fact that more and more in the product development world embedded software becomes a part of the product. And like in PLM where we want to manage the product data through its lifecycle, ALM should become a logical part of a modern PLM implementation. Currently most of the ALM applications in this context are isolated systems dealing only with the software lifecycle, see this Wiki Page
ALM = Asset Lifecycle Management (operational)
In 2009 I started to focus on (my type of) ALM, called Asset Lifecycle Management, and I discovered the same confusion as when you talk about a BOM. What BOM really means is only clear when you understand the context. Engineers will usually think of an Engineering BOM, representing product as specified by engineering (managed by PDM). Usually the rest of the organization will imagine the Manufacturing BOM, representing the product the way it will be produced (managed mostly in ERP).
The same is valid for ALM. The majority of people in a production facility, plant or managed infrastructure will consider ALM as the way to optimize the lifecycle of assets. This means optimizing the execution of the plant, when to service or replace an asset ? What types of MRO activities to perform. Sounds a lot like ERP and as it has direct measurable impact on finance, it is the area that gets most of the attention by the management.
ALM = Asset Lifecycle Management (information management)
Here we talk about the information management of assets. When you maintain your assets only in a MRO system, it is similar like in a manufacturing company when only using an ERP system. You have the data for operations, but you do not have the process in place to manage the change and quality of data. In the manufacturing world this is done in PDM and PLM system and I believe owners/operators of plant can learn from that.
I wrote a few posts about this topic, see Asset Lifecycle Management using a PLM system, PLM CM and ALM – not sexy or using a PLM system for Asset Lifecycle Management requires a vision and I am not going to rewrite them in this post. So get familiar with my thoughts if you read the first time about ALM in my blog.
What I wanted to share is that thanks to modern PLM systems, IT infrastructure/technologies and SBA it becomes achievable for owner/operators to implement an Asset Lifecycle Management vision for their asset information and I am happy to confirm that in my prospect and customer base, I see companies investing and building this ALM vision.
And why do they do this:
- Reduce maintenance time (incidental and planned) by days or weeks due to the fact that people have been working with the right and complete data. Depending on the type of operations, one week less maintenance can bring millions (power generation, high demand/high cost chemicals and more)
- Reduce the failure costs dramatically. As maintenance is often a multi-disciplinary activity errors due to miscommunication are considered as normal in this industry (10 % up and even more). It is exactly this multi-disciplinary coordination that PLM systems can bring to this world. And the more you can do in a virtual world the more you can assure you do the right thing during real maintenance activities. Here industries similar as for the previous bullet, but also industries where high-costly materials and resources are used, the impact on reducing failure costs is high.
- Improve the quality of data. Often the MRO system contains a lot of operational parameters that were entered there at a certain time by a certain person with certain skills – the fact that although I used the word certain three times, the result is uncertainty as there is no separate tracing and validation of the parameters per discipline and an uncertain person looking at the data might not discover there is an error, till it goes wrong. Here industries where a human error can be dramatic benefit the most from it (nuclear, complex chemical processes)
Conclusion: The PLM system based ALM implementations are more and more becoming reality next to the ALM operational world. After spending more then three years focused on this area, I believe we can see and learn from the first results.
Are you interested in more details or do you want to share your experience ? Please let me know and I will be happy to extend the discussion
Note: On purpose I used as much TLA’s to assure it looks like an specialist blog, but you can always follow the hyperlink to the wiki explanation, when the TLA occurs the first time.
The trigger for this post is based was a discussion I had around the Autodesk 360 cloud based PLM solution. To position this solution and to simplify the message for my conversation partner Joe the plumber, I told him”: “You can compare the solution with Excel on-line. As many small mid-market companies are running around with metadata (no CAD files) in Excel, the simplified game changer with this cloud based PLM offering is that the metadata is now in the cloud, much easier to access and only a single version exists.”
(sorry for Autodesk, if I simplified it too much, but sometimes your conversation partner does not have an IT background as they are plumbers)
He was right and I had to go more in-depth to explain difference. This part of the conversation was similar to discussions I had in some meetings with owner / operators in the civil and energy sector, discussing the benefits of PLM practices for their industry.
I wrote about this in previous posts:
The trouble with dumb documents
Here it was even more a key point of the discussion that most of the legacy data is stored in dumb documents. And the main reason dumb documents are used is because the data needs to be available during the long lifecycle of the the plant, application independent if possible. So in the previous century this was paper, later scanned documents (TIFF – PDF) and currently mainly PDF. Most of the data now is digital but where is the intelligence ?
The challenges these companies have is that despite the fact information is now stored in a digital file, the next step is how to deal with the information in an intelligent manner. A document or an Excel file is a collection of information, you might call it knowledge, but to get access to the knowledge you need to find it.
Did you try to find a specific document in Google docs or SharePoint ? The conclusion will be the file name becomes very important, and perhaps some keywords ?
Is search the solution ?
To overcome this problem, full text search and search based applications were developed, that allow us to index and search inside the documents. A piece of cake for Google and a niche for others to index not only standard documents but also more technical data (drawings, scans from P&ID, etc, etc).
Does this solve the problem ?
Partly, as suddenly the user finds a lot more data. Search on Google for the words “Right data” and you have 3.760.000.000 hits (or more). But what is the right data ? The user can only decide what is the right data by understanding the context.
- Is it the latest version ?
- Is it reflecting the change we made at that functional position ?
- What has changed ?
And here comes the need for more intelligent data. And this is typically where a PLM system provides the answer.
A PLM systems is able to manage different types of information, not only documents. In the context of a plant or a building, the PLM system would also contain:
- a functional definition / structure (linked to its requirements)
- a logical definition / structure (how is it supposed to be ?)
- a physical definition / structure (what is physically there ?)
- a location definition / structure (where in the plant / building ?)
and this is all version managed and related to the supported documents and other types of information. This brings context to the documents and therefore it exposes knowledge.
As there is no automatic switch from dumb documents towards intelligent data, it will be a gradual process to move towards this vision. I see a major role for search based applications to support data discovery. Find a lot of information, but than have the capability to capture the result (or generate a digest of the result) and store it connected to your PLM system, where is it managed in the future and provides the context.
Conclusion: We understand that paper documents are out of time. Moving these documents to digital files stored in a central location, either in SharePoint or a cloud-based storage location is a step we will regret in ten years from now, as intelligent data is not only inside the digital files but also depending on its context.
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.
- 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