Towards an information model for projects
My first job was as a software developer in a major Spanish EPC company. I was hired to develop a search engine able to query the myriad of different systems and in-house applications available in the company and provide web-based consolidated views of this information. Then, a subset of this information and a customized set of applications were replicated to the Internet web servers of the company.
Those applications were made for our providers and customers, ultimately the facility owners, in order to work with the currently open material requisitions and being able to check the project’s progress respectively. It was presented as read only information and was difficult to deal with, as orders, equipment, material requisitions, progress tracking were all managed with a different data model and it was problematic to discover the nodes relaying the data: quite often an equipment number, tag or document number.
As a developer, it was quite annoying to be thinking: "No one has thought of a common data model for all this stuff." Furthermore, suppliers and facility owners had their own set of systems and applications too, making data exchange a manual process in the majority of cases regardless of the technology used for data transmission (e-mail, ftp, etc).
It was easy to grant access for the latest project documentation to the customer, but it was quite different when it came to the related information living in other systems. In other words, a "Document-centric" mindset dominated project development.
Every Document Counts
As part of an EPC project, each and every document counts: every drawing, calculation, specification is a document in a list of deliverables. This is why the metaphor of the documentation repository works so well: in the old times the project was made up of (real) cabinets with (real) folders and (real) documents in it. Recently, the world has shifted to electronic documentation with all of the benefits we all know and love with the documents repository at the centre of it all. But all this information can only provide you with exactly that: documents.
Apart from this, everything pertaining to scheduling, budgeting and a plethora of other information is stored in separate databases and commercial applications. So, the complete information set about, say, "this valve", is still disparate and disconnected.
The evolution of CAD software from 2D to 3D and the eruption of PDMS software, has resulted in companies being able to actually design facilities in 3D. When you create something in 3D, it is said that you’re creating a "model", not just a "drawing". This model is just a physical representation of the objects, but now EPCs can see the results of their work in 3D on their screens, not in their imagination or recreated in the form of hand-made models. Their mindset has shifted to a "Model-centric" one.
PDMS software has allowed everyone to walk through the facility as it was being designed and constructed. This mindset fits much better with the ultimate goal of the project: the actual facility being constructed. Yet still, this model approach is not standard, depends on different software manufacturers, and it’s up to every company in the project ecosystem to have it.
Nevertheless, this is a huge step towards a centralised model, as PDMS models allow the integration of information from different systems. The BIM (Building Information Model) standard is the next evolutionary step in this chain.
The BIM Factor
In short, BIM is a set of software technologies, standards and processes to create a model of the facility being constructed, in such a way that the model features not only its physical representation in 3D but also the functional characteristics of each and every one of its components. External information such as documents or budgetary information living in separate applications can be related to the model as every piece in the model features an ID.
BIM is paving the way towards an "Information-centric" mindset for all the companies involved in the development of capital projects, and it is important for oil and gas companies because it allows them to play a more active role in the project development of their facilities and their future operation.
As you will be anticipating, in the information-centric model the goal is to have everything related. To have the facility designed in 3D, being able to navigate it and if you click on our valve, to obtain all its related technical information, technical documentation, as well as its budgetary (4D) and scheduling (5D) information. This is the essence of BIM. But there’s more, because BIM is designed to allow concurrent engineering by leveraging two critical concepts: the information model standard (http://www.nationalbimstandard.org/) and the concept of a central information repository.
These two concepts are directly taken from information technology, and means that all the players involved in the development of a project will be sharing the same information, the same information model and exchange standards. This will highly improve the "collaborative by nature" documentation creation processes involved in capital projects.
Although in its conception it was primarily aimed for architectural and construction processed, BIM is the enabler for a mindset the business has been pursuing for decades. It sets an information standard that all other applications can follow or at least, relate to, making things much easier since all players share a common central point of reference.
In my opinion, this approach will make a huge impact in the role IT departments play in the capital projects ecosystem. But, as every standard, its success will depend on its progressive awareness and adoption.
For more energy insights, visit EMC Spark today.