Defining Information

Information is a broad term and has many facets, so let’s classify exactly what it means. First, the information that describes the asset as a component in a facility, its purpose or classification, its size, capacities, limitations, etc., is known as its functional attributes. Second, where the asset functions within the facility, how it is connected to other assets, and how it is controlled and monitored is its associations. Third, information about the particular physical asset, such as its manufacturer, model, serial number and age, refers to its physical attributes. Lastly, information from the past, date installed, how it was commissioned, time in operation, performance data, maintenance performed, etc., is its historical data.

In summary:

• Functional Attributes – its purpose and design;
• Associations – its place in the world;
• Physical Attributes – what it is today;
• Historical Data - what happened in the past.

Systems of Record

Because these four types of information are different, to be managed effectively, each category would benefit from a different method for collection, storage and searching. But experience shows information is usually captured and maintained in just two systems of record: a document management system (DMS) and a computerized maintenance management system (CMMS). Both are probably maintained and owned by different departments, creating silos of data.

There may be a third system, a historian or archive of operating data that is often part of the facility’s control system. It holds a lot of data, but doesn’t describe the facility or provide fundamental information.

For a good information foundation, one needs to define the information correctly, have a complete set and store it in effective systems of record. It sounds logical and is certainly not rocket science, so why is industry still struggling to manage information and, therefore, maintain the knowledge. It’s an anathema, especially when one considers the power of computing now available at one’s fingertips (e.g., tablets) or the huge gains in connectivity we now take for granted with the Internet.

Consider these important issues.

Laying the Initial Foundation

Information is usually in the best shape at the handoff from project to operations. This start of information flow lays the foundation for the rest of the life of the asset.

Definition of Requirement

One issue is knowing what is wanted. The owner of the asset seems to have great difficulty defining what is required from the organization that designs and builds the asset. Why is that? One reason is the people involved in running the project are focused on delivery: on time, under budget. Building any facility is a huge endeavor, so the project manager (PM) could be forgiven for losing focus on something beyond his/her immediate concern. Operations people are involved in the project, but are unlikely to have comprehensive knowledge of the needs for every discipline. They need to rely on past knowledge.

Past knowledge is usually passed down in lists. Lists are often incomplete and lacking definition. A classic is the supplier document requirements list (SDRL), typically a two-page document listing broad categories like process diagrams, data sheets and spare parts list. The SDRL is often issued to every supplier of packaged equipment, irrespective of the type of package, so the supplier of a generator package could get the same requirement list as the supplier of a hydrocyclone package. Note: The SDRL is a document list, asking for a data-centric package is very novel!

Similarly, the information captured in the design, construction and commissioning phases faces similar issues. The definition is broad, driven more by what is available than what is needed. So at the critical point where there is a chance to get it right, the definition is: “We don’t know exactly what we want, so let’s get everything,” countered by, “Do you know how much that is going to cost?”

Efforts are being made to change this approach. Making lists by polling operations, using third-party experts to work with suppliers gathering information and making voluminous corporate lists and then trying to check off what is required at contract award time are all worthy, but are limited and expensive exercises. Relying on industry standards offers hope, so getting involved with organizations, such as Fiatech, is recommended.

Organization

Even if we get our definition right, can a project deliver? Let’s go back to our project manager who is focused on delivery. Ultimately, it is the PM’s job to create the organization to deliver.

Information technology (IT) would be responsible for providing the infrastructure. Networks, PC servers and software are big tangible costs to manage. Then, information management (IM) would manage what will be delivered. A significant cost is involved, but not quite as tangible as IT. Additionally, IM’s consequences in terms of success and failure are less visible to the project team. Yet, IT and IM get bundled together and defined as a service under project business services. This makes no sense. IT and IM need to be split, where IT can remain a service, but IM’s profile should be elevated and extended. Elevating IM’s role exposes it to decision makers in engineering, construction and operations. Extending IM’s profile integrates it not only through design and commissioning, but extends it into early operations so the transition can be comprehensive.

Systems of Record

What works as a system during design, construction and even through to start-up is not necessarily the right system for operations. Likewise, functionality in modeling, visualization and design are not necessarily the essentials needed to run the facility. To compound the challenges, existing operational systems are often legacy solutions embedded in corporate processes of control and access, shackled by leaner budgets and thinner support organizations that create many challenges. So even if innovative investments made during a project could be used in operations, sweeping away the old and bringing in a newer, more responsive solution would be a difficult sell.

Embracing legacy documentation in a new application can appear more costly than its perceived gain. As a result, inertia in status quo often stops innovation. So at the point when one should be in the best shape, ready with the foundation to operate efficiently in today’s world, we may be no better than 20 years ago. How can that be?

Exponential Volumes

The issue is volume. Twenty years ago, project deliverables were measured in meters of documents (i.e., paper centric). Delivering that paper was more arduous and took more time. Today, everything is delivered electronically, gigabytes moved at the click of a mouse. So, volume has exponentially expanded, while the rigor for delivery has diminished. Here’s a quick analogy: How many digital photos do you have? Are they better organized and more accessible than the old photo album you created on your first vacation?

Look at the types of documents a project generates and what needs to be delivered to operations.

Figure 1:

The risk is one that doesn’t focus on the critical, doesn’t manage the essential and doesn’t archive the necessary.

Addressing the Problem by Stealth

Without a doubt, issues can seem insoluble and the scope insurmountable. But certain approaches can be taken to start making a difference. These approaches are not revolutionary, need not be a huge expense and can work, partly because change works stealthy, below the radar. Consider these three recommendations.

Build Associations

This is key; without a way to build and retain associations between one piece of information and another, an organization is always reestablishing relationships. Accept that data will exist in silos, that’s legacy. To break through, an effective tool is needed that can link the P&ID with the tag, the line, the end device, the data sheet and the operating instruction. Plus, the tool needs to work with the silos of information and be integrated in the management of change processes.

Broaden Ownership

In a large facility, no one can be expected to have knowledge of all the details, or be an expert across all disciplines. Knowledge is lodged in the workforce. Tools are available for organizations to engage the workforce and tap into the knowledge. Web-based solutions, such as Wiki pages or social network tools, can help, but it is probably better to develop simple Web-based capture tools. Management must endorse and encourage staff to contribute and remove any onerous processes that stifle voices.

Reengineer MOC Processes

This is the final key in adopting a better way to capture and manage information, and a better way to change behaviors in the workforce. It is not complex, rather the organization needs to recognize a change is happening, quantify the change, make the change and verify that the change has been completed, including making the information correct.

View the process as a workflow, using available workflow tools. However, such tools are often part of a legacy system or a discipline-based solution. An effective process must embrace the two other recommended changes, associations and broader ownership.

Consider the diagram in Figure 2.

Figure 2:

Coupling association, ownership and process can lead to better quality, higher veracity and early recognition of deficiencies. Tools are available and although they are not silver bullets, they can make improvements, gradually. Each organization will have to work for a solution that fits its situation. But that solution need not necessarily be a mountain to climb, but more of a long road with many successes along the way.

When this approach has been explained to operations, actual cases have shown 100 percent endorsement to the approach. What’s more, two actual instances of retrofitting an association engine (engineering data warehouse) into daily operations and management of change processes proved highly successful. Why not try the stealth approach in your organization?