Establishing data governance is not a new activity. It is, at its heart, an extension of man’s desire to define the world, and to communicate these discoveries in a more efficient manner. A good data standard can be linked to the use of Latin as a lingua franca by merchants in medieval Europe. Few English merchants could speak Dutch, but most were taught Latin (and vice versa). Latin provided a set of definitions and rules understood by all, promoted by rote memorization of grammar and a large number of books, policed by data stewards in the form of tutors who rapped children’s knuckles when they got it wrong.  (ok, maybe this is a stretch a bit, but I like the story :-))

Not a Blank Slate

In Oil and Gas, I see data governance programs in many forms, from centralized formats to a completely distributed approach, and everything in between. These implementations come with varying degrees of success.

So when I came across Robert Seiner’s book “Non-Invasive Data Governance” I asked myself could this work for oil and gas? In my judgment, a distributed, organic, and non-invasive approach could be an option to deploy a data governance program in a faster, more uniform and comprehensive manner, which in turn would yield better success.

Non-invasive data governance is built around identifying already in place, de facto standards, and processes to capture and manipulate data. If there isn’t one standard, then “converging” and “formalizing” to one standard that suits is put in place. In the new world, data stewards will be recognized “formally” and will maintain “universal” standards for work they have been doing all along…

To me, this approach has far-reaching implications to raise the bar on data quality standards. This approach weaves the quality standards in the DNA and the culture of an organization.

Business Specific Pidgin

Let’s continue the historical analogy a little. Trade was still conducted without the advantage of a lingua franca, albeit with greater difficulty. Typically, this was accomplished by the evolution of pidgin languages. The first encounters, however, were most likely exercises in frustration, as both parties attempted to learn one another’s needs, defined goods and services, and the perceived value of these. In speaking a pidgin language with another merchant, if either party used a differing definition, or even presented his offer in an unfamiliar sentence structure, the business venture could go south very quickly. Similarly, within a single oil and gas organization. For each data group, there needs to be one standard for all.

The oil and gas industry would not be where it is today without some established data standards and data processes already in place. Data governance will never be a blank slate. The problem is that while standards exist that are recognized across the industry, there are many terms that differ from one team to another and are not quite formalized or fully recognized.

The non-invasive DG approach is to formalize what is currently not formal and monitor it for continuous improvement over time. For example, wellbore survey data can be captured in different ways, none of which are wrong, just different. One team would store latitude, longitude, geodetic system, Easting, Northing, and distance. Another team might use Negative and Positive to indicate directions instead of Easting and Northing. These are very subtle differences, however, when flowing data from one system to another (and data flow we do a lot) a level of accuracy is lost in the translation.

Let me know your thoughts…

 

If like many oil and gas companies, your technical documents are scattered, or buried in folders and nested folders, you have an opportunity to increase the efficiency of your petro-professionals by organizing their technical documents, speed up how they locate these documents, or better yet, do both. If you do it right, you can architect a solution that is sustainable.

Organizing electronic files for an oil and gas company is not as complex as it first may seem. It is very similar to the way you organize files and documents on your PC. The fundamental question you must ask yourself is “ How do I sustainably tag or organize my files so that I can find what I need in 5 seconds or less?”. This question guides my efforts for all designs and solutions that I help my client’s engineers and geoscientists build. The topic is big and long, but here I would like to share my thoughts on architecture.

This topic is big with many angles, for this blog I would like to share my thoughts on architecting the technical documents healthy environment.

This Valentine’s month: Separate for Sustainability

Many oil and gas companies do not distinguish between the active work area and a long-term final-version area for their electronic files. What we find instead is one environment with ALL technical files in one place. This repository often contains both active and long-gone projects, including files for divested wells. Attempts to organize this chaotic mess happen every other year. This kind of architecture requires organizing these files every few years, with a hefty price tag!

 

In my opinion, for an oil and gas company to have a sustainable documents management practice, there should be at least 4 working areas within your environment (see diagram below).

An Amicable Separation

Area #1 Team work area

By establishing a day-to-day work area that can by definition be an organic mess coordinated by those who know exactly what everything is, your team can collaborate in whatever method works best for them. This area is usually cluttered with analyses files, multiple versions of a document, manuals, research material, cost proposals from vendors, and more.

This flexibility is key to a productive, happy work environment. It only becomes a problem when others are exposed to a ‘mess’ that is not of their own making. For this reason, each team should have their own defined work area.

(Yes, I hear some of you say today’s technology are designed curtail this mess and no need to have a separate work environment. I think that may be possible if the technology is used by a homogenous skilled staff.  Oil and gas staff are of all ages and at different levels of software savviness)

Area #2 Final versions area

Separating your final-versions area from the working area has two immediate benefits

1) Efficiently and effectively declare and distribute the final version to the enterprise

2) Allows the removal of inactive files from work area (declutter).

Your final versions area should provide access to (and the easy identification of) the latest version of a report in a timely manner and without delays. Unfortunately,  this area is often not formalized (it is not separated from area #1), causing delays for other teams who need access to a given file – they need to notify your team, have a member of your team identify the correct file, and then possibly to send them the file.

Often, distribution of final versions is a complex dance of requests and delivery between multiple teams or individuals. By separating the archival/final versions area, and providing access to authorized resources, this jitterbug contest can become a synchronized line dance. If all parties that need a file can identify the right file on their own, and retrieve it themselves, significant delays can be avoided.

Furthermore, by separating the final-version area from a work area, you have a chance to sustain the serenity and completeness of technical well files and specifically well files and records (most important assets you can have). Allowing any company to easily open a data room when and if needed.

Areas # 3 and 4: External Collaboration and Access

When considering work areas and final versions, it is important to consider accessibility, external as well as internal. Providing data to JV partners bases on their WI and JOV data requirements and collaborating with vendors during well directional design or completion treatment is essential to keeping the technical documents preserved and not lost in a web of email attachments.

To me, this architecture is non-invasive or intrusive to engineers and geoscientists workflow.

Summary: Separate, but don’t go far

Separating final-version area from work area can have an immediate and strong benefit to productivity, balancing team flexibility with the requirements of other teams in the organization. While the day-to-day work area should be organic and flexible, it is important that the Archival/Final Version repository is defined. This is because it is not serving just one team, but the needs of an organization as a whole. This separation of working area and final versions/archival area provides a sustainable solution that meets the 5-second accessibility requirement outlined above.

Having outlined the benefits of this simple change in a complex working environment, we’d love to hear from the community. Do you have a better approach? Questions regarding implementation? Have you implemented something like this, and if so, what was your experience? Whatever the input, we would love to hear from you.