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