LCI – Document package or continuous process?

LCI or LifeCycle Information is a hot topic in the Norwegian Oil & Gas industry. For my international readers who do not know this term, it has to do with managing huge amounts of documentation from plant engineering through product engineering and fabrication. Then cross checking it all through multiple iterations. The documentation is then supplied to the Operator at several milestones in the project from early design through commissioning.

A more international term would be preparation of Documentation For Installation (DFI) and Documentation For Operation (DFO).

Rigorous demands on LCI from the operators
Operators put rigorous demands on what information they want in a project, and at which points in time they need it due to their need to monitor progress in the projects, and to be compliant with safety and regulatory standards. The Engineering procurement & construction contractor is responsible for collecting, checking and supplying the documentation from its own disciplines as well as all suppliers in the required way.

LCI Coordinators
Traditionally it has been the domain of a whole host of LCI Coordinators to make sure that all documentation is present and if not, make sure it is created…. However the “best” LCI coordinators manage to produce the information without “bothering” engineering too much. It has largely been a document centric process separated from the plant/product engineering process.

Varying LCI requirements from operators
One of the real headaches for the EPC’s are the varying requirements from different operators in different countries or especially when the end customer is a yard. I’ve witnessed rigorous and detailed LCI deliveries in a project for an operator, and a completely different set of deliveries for a yard. This challenge has led to more EPC’s defining their own LCI strategy and processes as their own best practice, while treating requirements from operators in different parts of the world as “add-ons” to their already existing LCI process.

Going from document-centric to data oriented approach
In recent years, I’ve started to see a shift from the separated document centric approach to a more data oriented approach where data is harvested from different data structures, or linked data in context if you will. This process is no longer separate from the plant design and project execution process, but rather an integrated part of it. This shift is very similar to how the aerospace industry is executing their projects. One such example is Airbus DMU (Digital Mock Up). With this approach it is easier to share and collaborate on data. Dependencies and consequences of changes are more easily understood and experiences can be harvested from one project to the next by copying data structures from one project to the other. Some EPC’s are also creating best practice template structures or libraries. I've seen this approach used successfully to facilitate re-use and to minimize engineering time during FEED phase (Front End Engineering & Design) and also during contract execution.

If you want more information regarding the differences between a document centric and data oriented approach I would recommend Jos Voskuils blog series on the subject.

CONCLUSION
The Oil & Gas industry is under pressure to save money and be more efficient. LCI is one of the domains where there is a lot to be learned from other industries. Building the LCI processes into your engineering and project execution processes will greatly reduce the LCI effort. Of course this demands that you have some way to collect, control and consolidate engineering and design data from various sources.

Bjørn Fidjeland
www.infuseit.com

When product design meets plant design

I’ve been fortunate enough to work with some EPCs (Engineering Procurement and Construction companies) that also owned product companies in order to control more of the value chain. In these companies I’ve witnessed some very interesting discussions between plant engineering and product engineering. They often have a really hard time understanding each other.

Communication Problems

A typical situation is when plant engineers and product engineers come together to discuss PLM, and a way to create a consolidation platform for both plant and product engineering in a project execution context. This often results in a failure to communicate. The tools, processes, language and culture usually differ between plant engineers and product engineers. They have different vocabulary and focus. This can be accommodated by learning the language and understanding the culture. It is more challenging when they think they talk about the same, but in reality talk about very different things. As an example: Systems Engineering is for a plant engineer very different from Systems Engineering for a product engineer even if both of them can talk about functional decomposition.

It is crucial that enough effort is spent on making them understand each other. Then you can start finding the points of interaction and overlaps.

The business objective

• Plant engineering: The general idea is usually that plant engineering wants to re-use more across projects. Every project (customer delivery) is Engineer To Order, but by copying parts of some other design that was similar, or modules from a “Best Practice” library the EPC can reduce the amount of engineering hours spent in proposal or FEED (Front End Engineering and Design) phase.
• Product engineering: Product engineering usually also delivers project specific product designs, but would like to move in the direction of standardization while still having control of the project specific product deliveries.

How can this be done?

Consolidating and integrating plant and product engineering

In most of the cases I’ve seen where they consolidate plant and product information, some kind of product master library or catalog is created. The catalog holds the plant aspect with tag structure and functional requirements seen from plant engineering (a tag structure).

In addition it contains the product aspects with at least a generic product design (generic EBOM ) for the product, and in some cases a commercial representation of the product (sales structure).

This would mean that plant engineering could pick products or systems from the library and get an auto generated tag structure with requirements corresponding to the plant view of the product or system, whereas product engineering could be notified if a demand for further product engineering is required for the product in that specific project.

This is all very well until plant engineering and product engineering start figuring out what the actual content of the library or catalog should be. There is a substantial language barrier there, and the main issue is that they will use the same terms but mean very different things. Terms like functional location, functional decomposition, systems engineering are similar in both plant engineering and product engineering.

The difference is that the plant person will think of tag structures, P&ID (Piping and Instrumentation Diagrams), functional decomposition and requirements needed to design, build, operate and maintain the plant as a whole which means that only a subset of information is needed for each individual product. The product person will think of the products requirements, functional, logical and physical views (RFLP) of the entire product.

This can lead to long discussions where everybody thinks that they understand each other. It seems that they agree and start implementing a solution. After some time it becomes evident that they need very different things from the product master library.

What is my conclusion?

It is extremely important to agree on definitions and terms. What they mean to different stakeholders and what they should mean to the company. Product engineering should show and explain how products are designed to the plant engineers, and the plant engineers should show and explain how plants are designed and what information is needed to the product engineers. This exercise should be done as early as possible to avoid costly misunderstandings between the two domains. I would even go as far as saying that it would be a good idea to do this even if the EPC does not own the product companies.

Bjørn Fidjeland
www.infuseit.com

PLM for plant design projects?

When I started out on my PLM (Product Lifecycle Management) journey more than a decade ago it was hard for me, coming originally from oil & gas, to understand the difference between  the functional decomposition (tag structure) used in multi-discipline plant design, and the EBOM (Engineering Bill Of Material) used in traditional manufacturing industry. It was easy however, to see the language differences and the fact that PLM focused on BOM and serial production

Having worked with PLM in different industries it is now clear for me that PLM can have a significant role in project-focused industries like in plant design projects. What PLM systems are really good at is creating a globally accessible information backbone, connect this information to processes and connect the processes to people to ensure that the right information is there at the right time so that people can take decisions based on the latest approved “version of the truth”.

Using a PLM system can give a lot of benefits over the traditional way of doing plant design projects, where information and experience tend to be locked in different information repositories and systems in each project. Each project has its own IT infrastructure and setup of tools, and it becomes very hard to reuse knowledge, processes and parts of the design from one project to the next.

If all design information was in a PLM system, an EPC could consolidate all the plant design disciplines, connect the design information as deliverables in the project plan and monitor the projects progress in real-time.  Change management processes could be enforced, design templates could be used, partial designs could be copied from one project to another, equipment requirements could be selected from a catalog and all of it across projects. These are just a few of the benefits that could be harvested.

So why has this not been done a long time ago?

Well, in my view there are two main factors.

One is that there have not been sufficient drivers to do so in the past. One of the primary drivers for changing from a project centric approach to an approach that promotes reuse, harmonization of processes and standardization is cost pressure and competition. We’ve seen this in every industry that has adopted PLM. It’s not until the margins really suffer that PLM gains any real traction. At the moment we see that as a result of the above mentioned factors, there is a growing interest in PLM among several large EPCs.

 The other factor is the actual design process and the tools used. They differ quite a lot between plant and product design.

The difference in process however is not the main challenge. There are several PLM systems that are flexible enough to allow such processes to be created.

The main challenge lies in the fact that in order for a PLM system to work effectively, all the design information must flow from the design tools into the PLM platform. Not many PLM systems today have good integrations to plant design tools, so hence it is difficult to leverage all the benefits that a PLM system could bring. In product design it is quite different, since almost all PLM systems have integrations to most product design tools.

So am I saying that PLM should not handle plant design projects?

Actually no, because there is one other development in the industry that has led to a golden opportunity to get all the needed information into PLM systems and start harvesting the benefits.

There has been a lot of pressure recent years especially from Owner/Operators to standardize information exchange between all the parts of the value chain. From Owner/Operator, through EPCs and  product companies.

The need to consolidate internal disciplines for the EPC, but also to communicate with outside parties like product companies and especially to support the big handover of information from EPC to Owner Operator after installation and commissioning has led to a lot of focus on standardizing information exchange. One such example is ISO 15926 and the preferred exchange format XMpLant. Most plant design authoring tools are claiming to support this standard today. In my view, this is the key to bringing all of the engineering information under process control in a PLM system. From here it can be shared with internal parties, but also to externals, like the Owner/Operator or product companies.

Essentially, this is killing two birds with one stone.

What is my conclusion?

PLM systems “out of the box” are not suited to support plant design projects. However, PLM systems are very much suited as a platform for consolidating plant design information and processes across all disciplines in a plant design project provided that they support information exchange in a standardized manner like with ISO 15926 and XMpLant.

Such a PLM system would solve two major headaches for the EPCs. Firstly, the internal consolidation and follow up of the internal disciplines, and secondly the ability to exchange information with other stakeholders in the project in a standardized manner.

Those PLM platforms that are capable of scaling well enough, support standardized information exchange and handle the sheer amount of information involved in handling multiple plant design projects could have a bright future in this domain.