- 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.