Enterprise IT

In brief:

• Plant engineering remains one of the few bastions of resistance to the adoption of these general enterprise applications.
• What are the prospects for PLM and ERP in large-scale plant engineering?

Enterprise IT comprises four main pillars — enterprise resource planning (ERP), which is usually focused on managing money; product lifecycle management (PLM) to make sure that all involved parties have access to the right product data; supply chain management (SCM) to manage the flow of materials, goods, and services through the network of business partners and out to customers; and client relationship management (CRM) to make sure all activity associated with customer contact is optimized and coordinated.

Plant engineering — or, more specifically, large capital projects — remains one of the few bastions of resistance to the adoption of these general enterprise applications. The finance department would say this is because the engineers are awkward know-it-alls who just want to own and manage their own IT; the engineers say it’s because the finance people don’t understand the challenges involved. So which is it, and what are the prospects for PLM and ERP in large-scale plant engineering?

The developers of PLM and ERP systems have worked hard to adapt their systems to accommodate the demands of plant engineering and have certainly made some inroads at the operations end, where arguably the asset information and the associated processes that drive its use are more stable and repeatable. The fly, or elephant, in the ointment is that plant owners have for years been seeking the holy grail of a solution to their own lifecycle data management problems, that is, technology to manage the plant asset information from initial concept through design and construction into operation and all the way through to decommissioning. The enormous variation in the nature of the asset data and the ways in which they are used at different stages of that lifecycle continue to present major IT challenges. The effort is justified by the anticipated benefits; there are a number of in-depth studies that show the costs of poor data management, ranging from inefficient maintenance and overruns on plant modification projects to the potentially huge cost of non-compliance with safety regulations.

The problem has two components — technical and organizational. The difficulties are seeded by the capital project as the first phase, where the data relating to the potentially millions of elements of the plant asset are subject to frequent and often extensive change and rigorous processes are required to manage the evolution of the data across a potentially large number of design and construction project participants. Data and processes are tightly integrated; on complex projects there are many gateways and checkpoints that need collaborative review and agreement. To compound things further, the high volumes of design data are being produced by a number of major applications supporting a wide range of project disciplines including piping, mechanical, electrical, HVAC, and structural engineering. These applications embed the processes and data structures peculiar to their disciplines, making the technical challenge of a generalized approach to data management daunting.

The organizational challenge is no less daunting. Major projects involve a complex web of contractual relationships and responsibilities, and these change from project to project, such that in IT terms they suffer from a kind of “tragedy of the commons” problem. For example, were the holy grail of a viable singe data management environment to exist, who would own it and take responsibility for it? The natural answer is the plant owner, who would benefit from the ability to manage the data effectively over the plant lifecycle; but to what extent are the EPC firms and other project participants relieved of responsibility for project performance, given the imposition of what might be an unfamiliar IT environment? Who would pay for the onerous task of setting up the data management infrastructure? Would the owner be willing to absorb higher project costs for a downstream data management benefit?

As the phases of the capital project — concept design, detailed design, procurement construction — progress, the asset data accumulate, the volume peaking at project completion; there then follows the process of extracting the information that will be required for operation. Clearly, the easiest thing to do is to just hand over the whole lot, but this presents the owner with an almighty data management problem, unless that comprehensive data set could be filtered intelligently on the fly as appropriate when required for operations and maintenance tasks and new capital projects to overhaul or re-purpose the plant. Thus far, this is beyond the capabilities of PLM technologies, which excel in environments with a nicely structured, well-disciplined bill-of-material type taxonomy. In practice, even when the plant is well into its operational life, the sheer breadth of activities and required uses of the asset data confound attempts to build a data management environment in which things change against a reasonably stable backdrop and where the idea of a single version of the truth is achievable. It is usual for on-site engineers to inspect areas of the plant they need to work on. They may even initiate photogrammetric and other surveys because they expect existing documentation to be out of date.

Having painted rather a gloomy picture for engineering data management, things are just as challenging in the commercial sphere. Project procurement is a major discipline in itself. The process of requesting and evaluating bids for complex packages of work involves a high volume of interdependent data, technical and commercial, for wide variety of products. Managing and expediting huge numbers of orders, many of which will be subject to frequent revision as the project progresses, and seeing the cycle through to phased delivery, according to the often dynamic project plan, to site of materials, equipment, and services is a massive task. This world certainly does not fit well with a structured ERP procurement and inventory management model.

The result is that capital projects usually involve a plethora of systems and associated integrations and the resulting frustrations and inefficiencies that ensue. The IT industry is working hard to respond to the needs and, of course, producing an explosion of acronyms in the process — practically every possible permutation of plant, asset, lifecycle, information, data, and management.

Some ERP and PLM vendors have invested significant effort in understanding the challenges of managing plant asset data through the entire lifecycle of the plant and developing capabilities specific to the industry. PLM can be used by some of the product and equipment suppliers within their own domains and can then provide the resulting data to the project. Equally, ERP procurement processes are fine for some aspects of plant lifecycle procurement requirements. Partial use of ERP and PLM rather adds to the complexity of the IT environment, but the capabilities are evolving and their footprints on the plant asset data management problem are expanding. There are instances of efforts by owners trying to force-fit ERP and PLM technologies into their projects, but these so far seem to have involved prohibitively difficult process reengineering efforts. PLM and ERP vendors have, however, increased their open-systems attitude and moved from the large, service intensive deployments in large companies to address SME markets. Their architectures have evolved to allow greater configuration and also to allow interaction with specialist applications for aspects of the user’s business that they do not handle so well. Also, as ERP and PLM systems have increased their enterprise footprints — notably, the ERP vendors have expanded the concept of ERP to cover product data management — the overlap means they’ve had to become more flexible in terms of data ownership and interaction with complementary applications.

The counter-approach is to develop a data management environment that specifically embeds the required processes, is sufficiently flexible to accommodate data from the wide range of sources involved, and incorporates the intelligence to provide each of the many types of users throughout the plant lifecycle with the appropriate data. Any approach needs to be supported by a sophisticated document management framework. We are a long way from the elimination of documents as key-milestone-validation vehicles, contractual deliverables, and construction-site reference tools.

Which of these will prove most successful remains to be seen. Many plant owners have huge vested interests in maximizing the benefit and therefore the reach of their ERP and PLM investments, while the specialized plant-engineering vendors have the advantage of a deep understanding of the problem and extensive experience of the data and workflows involved. What is certain is that progress is being made in reducing the technology limitations of workable integrated data management throughout plant lifecycle. As this technology advances, the organizational and commercial limitations are exposed as limiting factors, encouraging better project setups.