PNEC 2015: White Paper
The Well Hierarchy as a Foundation for
MDM: A Case Study
Author
Steve Cooper, President, EnergyIQ
E: [email protected]
Well Hierarchy as a Foundation of MDM
Contents
Work Ownership and Copyright ................................................................................................................... 2
1.
Introduction .......................................................................................................................................... 3
2.
Supporting Information ........................................................................................................................ 4
3.
4.
5.
2.1.
Well Identification......................................................................................................................... 4
2.2.
Well Matching ............................................................................................................................... 7
2.3.
Aggregation ................................................................................................................................... 8
2.4.
Blending ........................................................................................................................................ 9
Building the Well Hierarchy: A Case Study ......................................................................................... 12
3.1.
Conceptual Well .......................................................................................................................... 13
3.2.
Planned Well ............................................................................................................................... 14
3.3.
Scheduled Well ........................................................................................................................... 15
3.4.
Drilling/Completing Well............................................................................................................. 16
3.5.
Producing Well ............................................................................................................................ 16
The Well Hierarchy as a Foundation of MDM..................................................................................... 19
4.1.
Geoscience MDM ........................................................................................................................ 19
4.2.
Enterprise MDM.......................................................................................................................... 20
Summary ............................................................................................................................................. 21
Work Ownership and Copyright
EnergyIQ retains ownership of the Work described in this material along with all other
copyright and intellectual property rights associated with the Work.
- 2-
Well Hierarchy as a Foundation of MDM
1. Introduction
The North American oil and gas industry is undergoing a step change that is being driven by
tremendous technical advances in the development of unconventional plays. Huge numbers of
wells are being drilled and completed with ever increasing complexity while the Well lifecycle
from planning through to production is being compressed.
Easy access to integrated data across the full Well lifecycle is a critical success factor for E&P
companies. Different people and groups within a company create and consume data at
different levels in the Well Hierarchy depending upon their role. For example:




A landman may be primarily interested in the surface location of a Well
A reservoir engineer will be concerned with the Wellbore and the producing formation
Drilling and completions engineers care about the Wellbore, Completions and
Perforations
The production accountant has to deal with all levels of the Well Hierarchy depending
upon internal and regulatory reporting requirements
Consistent integration of this data demands the ability to uniquely identify and relate a Well
and all of the Components of a Well consistently across the Well lifecycle. The resulting Well
Hierarchy can then be used to present a business view of the Well structure to the organization
and to link critical information across enterprise data stores to enhance workflow collaboration,
reduce errors, and increase efficiency. This linkage of critical information across business
workflows provides the foundation for a Geoscience MDM solution which, in turn, establishes
the critical domain in an Enterprise MDM implementation.
The PPDM ‘What is a Well?’ and Well Identification standards provide the foundation to
establish a comprehensive Well Hierarchy and achieve the level of lifecycle integration
necessary to meet the evolving needs of the business. These standards are gaining acceptance
across industry as an important communications vehicle. Their ultimate value, however, is
realized through implementation within a corporate Well Master database and as a foundation
for a Master Data Management (MDM) solution.
This paper details a practical approach to establishing a Well Hierarchy within a Corporate Well
Master and MDM solution. The case study described is based upon a number of solutions
delivered to large oil and gas companies through EnergyIQ’s commercially available Trusted
Data management (TDM) software.
- 3-
Well Hierarchy as a Foundation of MDM
2. Supporting Information
The Well Hierarchy is the relationship between those Components of a Well that are uniquely
identified. This section provides background information relating to the four primary processes
that are involved in building the Well Hierarchy:




Well Identification
Well Matching
Aggregation
Blending
When we think of the Well Hierarchy, typically we think of the Well or the Well Origin, the
Wellbore, and Completions within a Wellbore. However, there can be other Components that
are uniquely identified including Perforations (Contact Interval), Reporting Streams and
Wellbore Segments.
The level in the Well Hierarchy refers to the position of the Well Component relative to the
other Components of a Well. For example, it would generally be considered that a Completion
would be at a lower level than a Wellbore while a Well would be at a higher level in the Well
Hierarchy than a Wellbore or a Completion.
2.1. Well Identification
The PPDM ‘What is a Well?’ initiative was designed to provide a baseline set of definitions
and relationships for a Well and the Components of a Well that information is typically
attached to. The definitions were established by a consortium of both large and small oil
and gas companies along with service providers; see Figure 2.1.
- 4-
Well Hierarchy as a Foundation of MDM
Figure 2.1: What is a Well?
These definitions are gaining wide acceptance across industry as they enable companies to
establish a platform for communications and build a framework for data integration.
Following on from the ‘What is a Well?’ standards, the PPDM Association also established a
set of guiding principles for building a framework for Identification of the Well and
Components:
Framework Guiding Principle 1: A Well Identification System must be capable of
assigning an identifier to every Well Origin, Wellbore, or Wellbore Completion in its
scope.
Framework Guiding Principle 2: All identifiers assigned by a Well Identification System
must be permanent.
Framework Guiding Principle 3: All identifiers assigned by a Well Identification System
must be unique within that system.
- 5-
Well Hierarchy as a Foundation of MDM
Framework Guiding Principle 4: A Well Identification System must relate every
identified Wellbore to the Well Origin where it begins
Framework Guiding Principle 5: A Well Identification System must relate every
identified Wellbore Completion to the Well Origin and/or Wellbore(s) from which it was
created.
Framework Guiding Principle 6: The Global Framework must define the information
required for each part of the Well Identification System.
Framework Guiding Principle 7: Each part of the Well Identification System must have
an identified owner (Authority) and documented processes for the management of
change.
Working with a consortium of operating companies, EnergyIQ has adopted the PPDM ‘What
is a Well?’ definitions and these guiding principles to generate a system for enterprise Well
Identification, also known as the EKey:





Each Well and Well Component will be assigned a system generated surrogate key
known as the EKey. The EKey will be comprised of two parts; a sequential number to
identify the Well (Origin) and an additional suffix to identify all of the Well
Components
This identifier will never change over the life of the Well or Well Component (even
after abandonment) and will never be re-used
The WELL_LEVEL_TYPE attribute in the WELL table will be used to identify the Well
Component
The WELL_ALIAS table will be used to maintain the EKey and the original identifier(s)
The WELL_XREF table will be used to track relationships between the Well and the
Well Components
EKey
10001234
10001234-000
10001234-001
10001234-002
10001234-003
10001234-004
WELL_LEVEL_TYPE
WELL
WELLBORE
WELLBORE
COMPLETION
WELLBORE
COMPLETION
Table 2.1: Surrogate Key
The two part structure of the EKey and the relationship between the Well identifier and
the Component identifier is what is important rather than the physical length of each
section. Table 2.1 illustrates a common structure that has been implemented at a
number of large independent oil and gas companies:
- 6-
Well Hierarchy as a Foundation of MDM


The first part of the EKey is a system generated unique 8 digit number starting at
10,000,000 to avoid stripping leading 0’s.
The second part of the EKey is a 3 digit sequential number (starting at 000) that
identifies a Component of the Well (Wellbore, Completion, Perforation etc).
Beyond the fact that it identifies a Component of a Well, there is no implied intelligence in
the Component extension. Neither the value nor the order of the number should be
interpreted as having any significance.
Figure 2.2 illustrates one implementation of this approach where the Well Origin, Wellbores
and associated completions are uniquely identified. In addition, this illustrates how a new
Well Component, the Wellbore Segment, can also be uniquely identified through the same
approach.
Figure 2.2. Well Identification
2.2. Well Matching
A key part of building the Well Hierarchy is the ability to load and blend data from multiple
sources. As data is loaded from different sources, Well Matching becomes increasingly
important to ensure that the correct EKey is assigned to the right record. To add a Wellbore
to the Well Hierarchy, for example, it is necessary to determine whether the same Wellbore
already exists within the database:


If this is the case then the same EKey would be assigned
If not, then it is necessary to determine whether the parent Well has already been
defined, in which case the same 8 digit prefix would be assigned with the next
Component extension in sequence
- 7-
Well Hierarchy as a Foundation of MDM

If not, then a new 8 digit Well prefix would be assigned with the Component
extension of ‘000’ to identify the Wellbore
To meet these requirements, the Well Matching routines need to be able to support:





A set of configurable parameters for matching
Tolerances e.g. surface location within 5 feet
Weighting of the matching parameters
Match percentages e.g. 5 parameters out of 8 meet the match criteria therefore
there is a 70% match (after weighting)
Thresholds to define whether Wells match or not
Well Matching is not an exact science and so it is important to maintain an audit history
along with the corresponding tools to be able to review and iteratively improve the
matching process over time.
2.3. Aggregation
Aggregation involves the creation of a record at a higher level in the Well Hierarchy from
one or more from records at an immediately lower level in the Well Hierarchy. An example
of records that have been aggregated to create a full Well Hierarchy is illustrated in Figure
2.3. In this case, Completion level records have been Aggregated to create Wellbore records
which, in turn, have been Aggregated to create Well level records.
Figure 2.3: Well Hierarchy Aggregation
Aggregation depends upon a set of business rules that determine which attributes will be
promoted to the higher level record from the lower level records. By way of illustration, a
- 8-
Well Hierarchy as a Foundation of MDM
simple set of Aggregation Rules is included in Table 2.2 to promote attributes from multiple
Completion records to a single Wellbore record (and Wellbore to Well) based upon a
comparison between key fields such as Spud Date or Deepest Depth. In some cases, more
complex rules are required based upon a comparison of multiple fields and if-then-else
logic.
WELL_ATTRIBUTE
UWI
ABANDONMENT_DATE
ACTIVE_IND
ASSIGNED_FIELD
BASE_NODE_ID
BOTTOM_HOLE_LATITUDE
BOTTOM_HOLE_LONGITUDE
CASING_FLANGE_ELEV
CASING_FLANGE_ELEV_OUOM
COMPLETION_DATE
CONFIDENTIAL_DATE
Completion to Wellbore
Rule
Sequence/Calculated
MIN(SPUD_DATE)
MAX(COMPLETION_DATE)
MIN(SPUD_DATE)
MAX(DEEPEST_DEPTH)
MAX(DEEPEST_DEPTH)
MAX(DEEPEST_DEPTH)
MIN(SPUD_DATE)
MIN(SPUD_DATE)
MAX(COMPLETION_DATE)
MIN(SPUD_DATE)
Wellbore to Well Rule
Sequence/Calculated
MIN(SPUD_DATE)
MAX(COMPLETION_DATE)
MIN(SPUD_DATE)
MAX(DEEPEST_DEPTH)
MAX(DEEPEST_DEPTH)
MAX(DEEPEST_DEPTH)
MIN(SPUD_DATE)
MIN(SPUD_DATE)
MAX(COMPLETION_DATE)
MIN(SPUD_DATE)
Table 2.2: Sample Aggregation Rules
Aggregation can become a complex process when it is considered that data can already
exist at various levels within the Well Hierarchy from different sources and this must be
factored into the processes.
2.4. Blending
Blending is the process of creating a single, most trusted record at a given level in the Well
Hierarchy from two or more records at the same level in the Well Hierarchy from different
sources. Figure 2.4 illustrates multiple sources of Well Header records that have been
Blended to create a most trusted version for consumption by the organization.
- 9-
Well Hierarchy as a Foundation of MDM
Figure 2.4: Multi-Source Record Blending
The Blending Rules are typically built around the source of the data. Each source of data
within the database is assigned a priority and, during the Blending process, the first not null
attribute is promoted to the trusted version based upon source priority. This is illustrated in
Figure 2.4 where the versions are displayed from left to right in order of descending
priority. The blue boxes reflect those attributes that have been promoted to the trusted
version.
The Blending Rules can be applied at an individual attribute or at a record level and they can
vary by region according to the available data and the preferences of different asset teams.
Figure 2.5 illustrates a Source Preference List for a subset of attributes within the Well
Version table (PPDM data model) that establishes preferences by table and attribute by
region to provide a high degree of flexibility in how the final Well Header data is blended
and presented to the organization.
- 10 -
Well Hierarchy as a Foundation of MDM
Figure 2.5: Source Preference List
As enterprise data management solutions evolve, it is also likely that companies will want to
establish source preference lists that are tied to the current phase of the Well lifecycle. As
the Well moves through the lifecycle, the Blending Rules would change to reflect the
varying sources of data and the improving quality of the data.
The application of these four processes enables companies to define, build, and maintain a
consistent and reliable Well Hierarchy that is a fundamental requirement for a comprehensive
E&P data management solution.
- 11 -
Well Hierarchy as a Foundation of MDM
3. Building the Well Hierarchy: A Case Study
This section discusses the workflows and processes that were followed to build the Well
Hierarchy at a number of large E&P companies.
The Well Hierarchy is built across the full Well Lifecycle from the initial conceptual Well through
to the producing phase for successful Wells. At each phase of the Well lifecycle, business events
occur that trigger the creation or movement of data; see Figure 3.1.
Figure 3.1: Business Events across the Well Lifecycle
During the planning phase, the proposed Well is created either within the Corporate Well
Master database or in an end user application such as Aries. At this point in time, information
will be exchanged between the end user application and the Well Master to register that an
event has occurred. Regardless of which way the data initially flows, the Well will be created
with a unique identifier at this time to create the foundation for the Well Hierarchy. Depending
upon the specifics of the implementation, either just the Well Origin level will be created or the
full Hierarchy.
As the Well progresses through the Well Lifecycle, additional sources of data will be generated
within end user applications such as Enertia, OpenWells, and WellView. This data will be loaded
into the corporate Well Master and must be matched to the correct level of the Well Hierarchy.
This is typically the most complicated aspect of building out the Well Hierarchy and requires
working with the business to establish what component of the Well is defined within the
application. In some cases, the information within the end user application will describe
multiple levels of the Well Hierarchy through the same identifier; to resolve this will require the
- 12 -
Well Hierarchy as a Foundation of MDM
involvement of the Data Governance team to make the difficult decisions. The same approach
will be required to integrate the solution with other enterprise solutions such as SAP or the
Quorum land management system. The key identifiers within these applications will need to be
tied into the Well Hierarchy at the correct level.
As the Well Hierarchy is being built out, a cross-reference table will be created that links the key
identifiers in the end user solutions with the Well Hierarchy. This becomes the critical
information for Well Matching and linkage both within the Geoscience MDM and the Enterprise
MDM; see Figure 3.2.
Figure 3.2: Well Alias Table
The following sections, describe a typical workflow of how the Well Hierarchy is built up across
the Well Lifecycle from an actual client implementation. It should be noted that the phases of
the Well Lifecycle described in this section will vary from company to company depending upon
their workflows and processes.
3.1. Conceptual Well
In this case, a Well is initially created within a GIS application by reserves engineers. At this
point, basic Well header information is passed into the Corporate Well Master (CWM) and
the full Well Hierarchy is built out comprising the Well, Wellbore, and Completion. From a
theoretical standpoint, only the Well Origin exists at this time and the Wellbore and
Completion should be created later. However, experience has shown that it is easier to
build out the full Well Hierarchy early since information will be added to these levels and it
avoids matching challenges later.
As can be seen from Figure 3.3, at this phase of the Well Lifecycle, there is a limited amount
of information from a single source. The Well has not been permitted at this time and so is
unknown outside of the company.
- 13 -
Well Hierarchy as a Foundation of MDM
Figure 3.3: Conceptual Well
It is worth discussing at what point should a Well be created within the CWM. Some
companies leave it late in the Well Lifecycle and only build out the Well Hierarchy within the
CWM or MDM solution if and when it begins to produce. In our opinion, this is too late and
results in errors being introduced and important information being unavailable to critical
workflows. The Well Hierarchy should be built as early in the Well Lifecycle as possible and,
typically, when a commitment is made to spend money and generate key information.
As can be seen from Figure 3.3, the Current Status of the Well is set to = ‘CONCEPTUAL’.
One of the key benefits to this approach is to be able to generate a report of the current
status of all of the company interest Wells across the Well Lifecycle. This is information that
has been traditionally difficult to track in disparate solutions and is a significant benefit to
organizations.
3.2. Planned Well
At some point, the Well moves from the Conceptual Phase to the Planning phase. In this
case, a record is created within Aries at the Completion level and this is loaded into the
Corporate Well Master and matched to the existing Well record from the GIS interface.
Once the Well Completion record has been matched and loaded, aggregation runs to build
out the same source record at the higher levels of the Well hierarchy. In this case a
Wellbore and Well level record would be created for this source.
- 14 -
Well Hierarchy as a Foundation of MDM
Once aggregation is complete, the two Well records are blended together at all levels of the
Well Hierarchy. Figure 3.4 illustrates blending at the Completion level, with the Aries data
taking precedence over the record from the GIS interface. This results in a blended ‘Gold’
record which represents the most trusted data that will be presented back to the
organization.
Figure 3.4: Planned Well
The Current Status = ‘PLANNED’ at this phase and is updated automatically from Aries.
3.3. Scheduled Well
The next phase of the Well Lifecycle in this case study is to schedule the Well to be drilled
within the RigView application. In this situation, the RigView data is mapped into the Well
Hierarchy at the Wellbore level. As can be seen from Figure 3.5, at this phase there are
three sources of information matched at the Wellbore level.
As with the previous example, aggregation runs to create the new source record at the Well
level of the Hierarchy. This means that now we would have 2 source records at the
Completion level and 3 each at the Wellbore and Well level since the RigView data does not
exist at the Completion level.
Upon completion of aggregation, blending runs at the Wellbore and Well levels to create
the golden record with the RigView data taking precedence over the previous two; see
Figure 3.5.
- 15 -
Well Hierarchy as a Foundation of MDM
Figure 3.5: Scheduled Well
The Current Status = ‘SCHEDULED’ at this phase and is updated automatically from RigView.
3.4. Drilling/Completing Well
The Well then moves into the Planning and Completing phase of the Well Lifecycle. In this
example, the information is managed within OpenWells. As with RigView, it was determined
that the OpenWells data would be matched at the Wellbore level of the Well Hierarchy, see
Figure 3.7.
At this stage, the Well has been permitted and so will have been assigned an API by the
corresponding State and will now also be delivered through commercial sources such as IHS,
DI or TGS. When the commercial data is loaded, the Well must be matched into the existing
Well Hierarchy. Typically the API number will not have been entered into the internal
sources and so matching must be completed using other attributes such as Well Name,
Operator, and Location.
The Current Status of the Well is set to ‘DRILLED’ and ‘COMPLETED’ or ‘BEHIND PIPE’
through this phase of the Well Lifecycle.
3.5. Producing Well
In the final phase of our case study, the Well moves into the producing phase. In this
example the production is tracked within Avocet at the Completion level and so the Avocet
- 16 -
Well Hierarchy as a Foundation of MDM
record is matched at the Completion level and then aggregated to the Wellbore and Well
level.
Upon completion of the aggregation, blending runs to generate the ‘Gold’ record at each
level of the Well Hierarchy; see Figure 3.6.
Figure 3.6: Producing Well – Completion Level
In the producing phase, there are 4 different sources of data blended at the Completion
level. At the Wellbore and Well level, however, there are6 sources of data blended, see
Figure 3.7.
This represents the full Well Hierarchy for this case study. More information will be added
to the Well as it matures and it is possible that additional sources of data will be added such
as when the Well is worked over or sold to another operator. It is also possible that the
fundamental structure could be extended. If additional Wellbores are drilled and complex
Completions performed, it may be necessary to add the Wellbore Segment component or
the Producing Stream component to achieve the appropriate level of data management
granularity.
- 17 -
Well Hierarchy as a Foundation of MDM
Figure 3.7: Producing Well – Wellbore Level
- 18 -
Well Hierarchy as a Foundation of MDM
4. The Well Hierarchy as a Foundation of MDM
The Well Hierarchy is a foundational component of any MDM solution since ultimately
everything ties back to the Well. This section discusses the progression from a corporate Well
Master to a Geoscience MDM and ultimately to an Enterprise MDM solution. The Well
Hierarchy is key at each stage of this progression.
4.1. Geoscience MDM
The Well Hierarchy within a corporate Well Master provides the foundation for a
Geoscience MDM solution as it establishes the framework necessary to link information
from other data stores to the correct Well Level. A cross reference table is built to maintain
relationships between the unique identifier within the Well Hierarchy back to the
corresponding identifier in the source system.
This enables users to query against the CWM and pull data in from other sources whether it
be internal to the company or external such as the State web site; see Figure 4.1.
Figure 4.1: Geoscience MDM
Some companies take this a step further, where they push the Well identifier from the Well
Hierarchy in the CWM back out in to the source system. This provides an added level of data
quality and integration since this identifier can be used for matching purposes between the
- 19 -
Well Hierarchy as a Foundation of MDM
application and the Well Master and also between applications to minimize the potential
for errors.
4.2. Enterprise MDM
Enterprise MDM solutions are focused on the integration of critical data across the
organization to realize workflow efficiency and effect an improvement in the bottom line of
the company. Enterprise MDM solutions are typically structured with multiple domains that
address different business functions. The Well Header is one such domain in the E&P space
and is often established as separate from the Corporate Well Master with its own set of
unique identifiers.
Figure 4.2: Enterprise MDM
Following the progression as outlined in this paper, however, the Corporate Well Master
can be established as the Well Header domain based upon a comprehensive Well Hierarchy.
This approach eliminates the requirement to establish and integrate different Well
Identifiers and leverages the CWM as a Geoscience MDM.
Whether or not the Corporate Well Master is directly integrated into the Enterprise MDM
solution or not, the Well Hierarchy as outlined in this solution provides the framework for
Well Identification across the enterprise.
- 20 -
Well Hierarchy as a Foundation of MDM
5. Summary
The North American oil and gas industry is undergoing a significant, technology driven change.
The Well lifecycle is being compressed and the need for collaboration between business units
has never been higher. This is especially true in the current environment with additional cost
pressure as a result of lower oil and gas prices.
Easy access to integrated data across the full Well lifecycle is a critical requirement for
successful collaboration. The challenge is that data is typically stored in silos and the
information is often tied to different levels of the Well Hierarchy which makes matching
difficult. Data is typically shared between groups by passing spreadsheets with inconsistent
identifiers and inconsistent Well level definitions which makes matching difficult and results in
wasted time and significant errors.
To address this issue, companies are increasingly creating a Well Master data store in which
they establish a Well Hierarchy with unique identifiers for all Wells and Well Components at
relevant levels of the Hierarchy. This can then be used to tie together identifiers across end
user applications at the appropriate level to establish a business view of the data and support
improved collaboration between work teams.
This paper has described the EnergyIQ approach to building a Well Hierarchy that is based upon
PPDM standards and practical experience working with a number of large independent oil and
gas companies. Four key components of the process to establish the Well Hierarchy have been
described:




Well Identification
Well Matching
Aggregation
Blending
The Well Hierarchy provides the structure to manage information within a Corporate Well
Master database in addition to providing the Well identification framework necessary within a
Geoscience MDM solution and as the Well Header domain within an enterprise MDM solution.
- 21 -