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

Variant management in engineer-to-order?

Many products come in a lot of different variants, for equally many different reasons. Growth in variance can be a big challenge, in the virtual world, as well as the physical world. Taking a structured approach to variant management can help you get back in control – if you do it right.


First of all: variant management is not equal to product configuration (even if it is a closely related topic which may very well be part of a variant management solution). Also, the solution for variant management might look very different depending on type of product and type of industry: Is it a highly industrialized product, like a car, where all variants are made from a finite set of standardized modules? Or, is it a complex, low volume product, where new variants are created “on-the-fly”, based on customer requirements?

Many industrial companies are in the latter category, supplying highly advanced products to demanding customers in industries like oil & gas, aerospace & defense and health care. Common to all of these are that they typically come from a very project oriented mode of working, which is reflected in the way they are organized and how information is managed. They do talk about products, they do have product catalogues, but every delivery of a product is organized as a project, which typically includes a substantial engineering effort. The product information tends to be treated as project specific, even if the major part stays unchanged between each delivery project. Reuse between projects is frequently done by copying rather than referencing, resulting in massive duplication of documentation as well as part numbers.

The economy of scale

Variant management in high volume manufacturing is driven by a desire to cover a wide variety of customer preferences with a limited number of products. This has resulted in products that are configurable by the end customer, as part of the ordering process. The emergence of product platforms has brought this concept further, allowing a large number of models to be derived from a common technical platform. One of the latest developments in automotive is "scalable platforms", from which car models of almost any size can be derived, with VW and Volvo as early movers with their MQB and SPA platforms respectively. It is no secret that these initiatives are huge investments, but both manufacturers expect to gain a significant competitive advantage through the economy of scale for shared components and modules, as well as shortened development cycles for future models.

For low volume products, where the typical mode of operation is engineer-to-order (ETO), variant management is not needed as an enabler to provide a larger number of variants, as each delivered product is anyway tailored to satisfy the requirements of each individual customer. Rather, variant management should be seen an approach to rationalize the way products are delivered, while maintaining the competitive advantage of being flexible towards the customer. The economy of scale is still a valid motivation for improved variant management, as far too many activities end up as a redundant effort, repeated in every single delivery project.

Where to start and what to do?

Although the streamlined configure-to-order (CTO) process of the automotive industry might be out of reach when you are dealing with low volume products, there are still many concepts which can be applied, if you are in the ETO-business.

First of all, you need to step back and take a look at your business model and strategy: are you aiming at speeding up your current delivery process, or are you looking for new ways to design and deliver your products? There might very well be a potential in automating repetitive tasks in the engineering process, employing for instance parameterized CAD-models to speed up drawing generation and CNC-preparation. In many cases, however, there is a much greater potential to be gained from avoiding repetitive tasks, rather than automating them. This is where modularization and product platform thinking can be of help. If most variants of a product can be made from a limited number of standardized modules, there are huge benefits to be harvested all along the product lifecycle, far beyond the engineering department. A few examples:

• It is easier to predict the cost of the complete product, when the cost of each individual module is known from experience.
• Component and material cost will be reduced when enabling the procurement to order larger volumes, gaining lower prices from suppliers. Better predictability for expensive, long lead items is another advantage.
• Quality cost is reduced, as each module has a standardized set of design documents, which can be improved over time.
• Production processes can be industrialized and optimized to a much larger extent, as the number of identical items increase.

Some companies might object that customer requirements will still force them to deliver unique products (and documentation) every time. This may be true today, but will it still be true if the customer was confronted with the choice of a standard product and a custom product at twice the price? Certain types of products are custom by nature, because of the surrounding environment. It would still make sense to standardize what can be standardized to reduce the engineering effort in the delivery process, saving time and money.

Success criteria

To succeed with variant management in a project oriented environment, it is critical that the organization is set up to properly manage the standardized building blocks, and that the information management systems in use support the new way of working. Most PDM and PLM systems have specific functionality for variant management, as well as the required support for engineering change management across projects. The single most important criterion, still, is to establish a dedicated organization for product management with sufficient funding to develop and maintain the standard product definition, to ensure that it is complete and up to date. Otherwise, there is a high probability that the project engineers will continue managing variants as they have always done: using "Save As".

Johannes Storvik
www.infuseit.com