PNEC 2015: White Paper The Well Hierarchy as a Foundation for MDM: A Case Study Author

Transcription

1 PNEC 2015: White Paper The Well Hierarchy as a Foundation for MDM: A Case Study Author Steve Cooper, President, EnergyIQ E: steve.cooper@energyiq.info

2 Contents Work Ownership and Copyright Introduction Supporting Information Well Identification Well Matching Aggregation Blending Building the Well Hierarchy: A Case Study Conceptual Well Planned Well Scheduled Well Drilling/Completing Well Producing Well The Well Hierarchy as a Foundation of MDM Geoscience MDM Enterprise MDM Summary 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

3 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

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

5 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

6 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 WELL WELL_LEVEL_TYPE 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 -

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

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

9 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 Completion to Wellbore Rule Wellbore to Well Rule UWI Sequence/Calculated Sequence/Calculated ABANDONMENT_DATE MIN(SPUD_DATE) MIN(SPUD_DATE) ACTIVE_IND MAX(COMPLETION_DATE) MAX(COMPLETION_DATE) ASSIGNED_FIELD MIN(SPUD_DATE) MIN(SPUD_DATE) BASE_NODE_ID MAX(DEEPEST_DEPTH) MAX(DEEPEST_DEPTH) BOTTOM_HOLE_LATITUDE MAX(DEEPEST_DEPTH) MAX(DEEPEST_DEPTH) BOTTOM_HOLE_LONGITUDE MAX(DEEPEST_DEPTH) MAX(DEEPEST_DEPTH) CASING_FLANGE_ELEV MIN(SPUD_DATE) MIN(SPUD_DATE) CASING_FLANGE_ELEV_OUOM MIN(SPUD_DATE) MIN(SPUD_DATE) COMPLETION_DATE MAX(COMPLETION_DATE) MAX(COMPLETION_DATE) CONFIDENTIAL_DATE MIN(SPUD_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 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

10 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

11 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

12 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

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

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

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

16 Figure 3.5: Scheduled Well The Current Status = SCHEDULED at this phase and is updated automatically from RigView 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 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

17 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

18 Figure 3.7: Producing Well Wellbore Level

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

20 application and the Well Master and also between applications to minimize the potential for errors 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

21 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