RFI_Attach_4_ONRR_IT_Modernization_Functional_Modules_Overview_Final_1.pdf

U.S. Department of the Interior

Office of Natural Resources Revenue

IT Modernization

Functional Modules Overview

Prepared by Booz Allen Hamilton

July 1, 2020

Updated: December 29, 2021

ONRR IT Modernization – Functional Modules Overview July 1, 2020 (revised December 29, 2021) i

Contents Purpose Financial Management Case Management Customer Relationship Management Mission Assist Desk Business Intelligence Risk Analytics Data Management Self-Service Portal

Purpose

This document captures product owner level information on the Department of the Interior (DOI) Office of Natural Resources Revenue (ONRR) proposed To-Be state functional modules. The goal is to provide a quick reference for ONRR stakeholders that fosters a shared understanding of each module’s purpose, its functional interrelationships with other modules, and As-Is pain points addressed.

With this information, the ONRR product owner(s) of its modernized IT system can easily point to the challenges that must be addressed during the design, implementation, and sustainment of the new system. These challenges must be discussed and addressed in advance and as part of requirements development and system design. The importance of a shared vision and knowledge of the functional modules will increase as requirements development accelerates. For example, interconnections of functional modules require careful consideration to streamline requirement efforts, reduce risk of functional redundancy, and ensure complete traceability of requirements to business processes.

This document contains eight sections, one for each proposed functional module. Functional modules are presented in line with the ONRR value chain activities they will likely principally support, from Collect-to-Disburse, to Ensure Compliance, then Report and Share, with supporting Manage Data modules presented last (Figure 1).

Capturing Business Process Reengineering (BPR) outcomes, each section describes the following eight module fundamentals:

• Overview: Provides a summary and defines key characteristics of the functional module

• Vision: Explains what the functional module enables for ONRR and its benefits

• Business Need: Captures background on the business functions supported

• As-Is Description: Summarizes ONRR’s current state as it relates to the functional module

• Module Goals: Highlights goals that implementing the functional module should accomplish

Figure 1. Functional module alignment to the ONRR future state Value Chain

• Pain Points Addressed: Highlights priority pain points identified during analysis of the As-Is or current state of business processes*

• Implementation Considerations: Highlights challenges, risks, and other factors that should be addressed as part of a proposed module solution to increase its likelihood of success. Included are assumptions that describe priority planning factors and implied decisions needed for successful implementation

• Integration with Other Modules: Identifies other functional modules and anticipated interdependencies to be considered during requirements gathering efforts and factored into implementation plans

* These functional module summaries highlight the most relevant pain points. This embedded document contains all pain points identified during the ONRR BPR effort: As-Is Pain

Points.xlsx

Financial Management

Overview The Financial Management system is the primary functional module supporting ONRR’s mission of collecting, accounting, and verifying that natural resource and energy revenue are properly disbursed to States, American Indians, and the U.S. Treasury. It supports the vital function of providing audit ready financial statements that are complete, reliable, consistent and timely to support organizational and departmental decision making, in line with the CFO Act of 1990.

Key to ONRR’s Financial Management system is the data exchange, facilitated by the data management module, with the Bureau of Land Management (BLM), Bureau of Safety and Environment Enforcement (BSEE), the Bureau of Ocean Energy Management (BOEM), Bureau of Indian Affairs (BIA), and the Office of Special Trust (OST). Concurrently, reported data from industry stakeholders will be integrated to accurately calculate requisite payments and appropriate disbursements. Approximately $10 billion in annual revenues will continue to be processed in the new Financial Management module.

Module Vision

Modernize ONRR’s Financial system, which provides core functionality needed to collect, account, verify, and ensure natural resource and energy revenues are properly disbursed

Use a cloud-based platform with COTS functionality

Deploy a system with no manual processes

Eliminate, to the extent possible, the need for software customization that can increase development costs and impede automatic security patches and system enhancements, thus reducing risk

Ultimately, through modernization, improve the flexibility, accountability, expediency, and manageability of ONRR financial processes

Business Need Finance and accounting are a critical mission function for ONRR. ONRR must perform timely collection, verification, disbursement and reporting of mineral revenue data to stakeholders, which include private industry, states, counties, parishes, other federal agencies, and tribes. A modernized financial management module is needed to address the following issues:

• Eliminate customization that exists in the current MRMSS module, which is a heavily customized, non-COTS version of Oracle Peoplesoft with legacy code that prevents efficient maintenance

• Reduce labor-intensive manual investigations and reconciliations through improved matching payments to receivables and production reporting

• Provide the ability to account for funds to the lowest level of transaction identification for financial reporting as statutorily required and pursuant to applicable accounting standards (e.g., FASAB).

As-Is Description MRMSS is a mixed financial system, which includes the hardware and software that ONRR uses to perform its revenue-related duties. MRMSS relies on major customizations of PeopleSoft® with custom built accounts payable, accounts receivable, and general ledger modules that were built over a decade ago and are updated as needed. Additionally, ONRR uses the Oracle Business Process Management SOA Suite (BPM SOA) and Oracle Business Rule (OBR) engine. MRMSS system is currently 100% outsourced at an IBM data center in Raleigh, NC, for production data with a contingency data center in Boulder, CO.

MRMSS accounts for federal and tribal minerals rents, royalties, bonuses, and their distribution/disbursement to the U.S. Treasury, counties, states, and tribes. However, portions of specific disbursement scenarios are removed from the MRMSS and processed in external Access databases and the updated information is copied back into MRMSS.

MRMSS issues bills for late payment or non-payment of royalties and other lease term obligations. Most of the input data for MRMSS Financial and other supporting PeopleSoft modules (i.e., Reference and Production) consists of royalty reports and production reports received from industry via an electronic reporting contractor. The current number of users within the MRMSS Community is estimated to be 1,000 ONRR and government users and 3,000 industry users.

Module Goals As-Is Pain Points Addressed

• Enable standard Federal accounting including custodial and fund accounting processes/practices

• Use a cloud-based solution (i.e., PaaS/SaaS)

• Update current processes and functionality

• Remove manual intervention

• Ensure data inputs integral to financial processes are accurate and reliable

• Automate reconciliations

• Automate reporting

• Limited matching ability of royalty reports to payment data due to non-unique IDs between the documents

• Manual reconciliation of data often needed

• Limited ability to efficiently modify the system for regulation-driven changes due to high customization

• Some data manipulation processes currently performed outside system (per management decision)

• Not all programs can access PeopleSoft (e.g., Bankruptcy, Audit, Appeals)

Implementation Considerations Changes dictated by new laws, regulations, or directives could have significant impacts with core functionality that was designed a specific way based on original requirements. As part of implementation, ONRR must make a policy decision: ONRR must either track money at the payment level (the specific receivable that the payment being applied to) or allow Payors to apply payments to a specific lease.

In addition to policy considerations, the core functionality of a new financial management system must accommodate a range of business needs. For example, it must accommodate transactions across nearly 50,000 leases with complex stakeholder relationships (i.e., multiple Payors on a lease, different lease statuses,) and be flexible to adopt to those changing relationships and changes in industry practices (like communitization agreements). A new system must also consider prior period adjustments that can go back 6 years on Federal and indefinitely on Indian leases. Business decisions around functionality, such as lease-level reporting, will require new business rules and payment instructions.

Business Design Policies / Regulations Risks

The system should be designed for full automation with the ability to flag records for manual review and intervention as an anomaly, not standard practice.

The module must adhere to required Federal financial reporting protocols. Changes to policies and regulations can force difficult to implement solutions. RSFA would need to be reviewed and potentially updated for targeted changes in reporting and paying protocols.

Implementing a new solution without fully understanding current processes and functionality (and underlying business rules) could delay or compromise implementation.

Technical Design Execution Stakeholders

Core functionality must be seamlessly maintained while enabling integration with other (new) functional modules. If ONRR moves to a COTS package, substantial care will be needed to ensure complex business rules for royalty reporting and disbursements can be handled without customization.

Data migration may be difficult given the history and volume of existing financial data. Accurate replication of existing business rules that are still relevant to the new To-Be process will need to be transferred to the new system.

Significant organizational change management will be needed with any new application, especially if an out-of-the-box financial system of record. The new system will require user training, including education on changed protocols involving reporting and paying.

Assumptions

• Most business rules within MRMSS Financials are expected to stay the same for the modernized implementation of the Financial module.

• ONRR answers the policy decision on payment matching to enable 100% matching or attribution of payments made by industry.

• ONRR embraces changing the way financial processes are currently done (i.e., moving away from the customized MRMSS Peoplesoft implementation and offline processes).

Integration with Other Modules

Overall, the Financial module will directly integrate with data management and point to / pull from other functional modules to support financial-oriented processes. Integration will be needed to:

Business Intelligence Generate financial reports

Case Management Provide supporting financial case data CRM Facilitate the gathering of clean, validated data that this module will process

Data Management Process financial transactions using the single-source-of-truth data Mission Assist Desk Facilitate stakeholder troubleshooting and support reporting functions

Risk Analytics Minimal integration; may track reporting violations to feed risk models Self-Service Portal Facilitate the gathering of clean, validated data that the module will process

Case Management

Overview A Case Management module manages relevant information that is collected and streamlined through workflows from initiation to resolution. An enterprise may have many functions across its value chains that a Case Management module can support, including, but not limited to, the typically thought of “compliance-related” activity. In addition, it can facilitate the aggregation of case data to view trends of systemic issues for leadership to inform policy, training, or regulation-level decision making.

Effective use of a Case Management module requires a clearly established case management framework, including a definition of “case” and “case management.” A case is a particular instance or work item; it is a unique situation involving complex interactions between content, people, business, evidence, and regulatory policies with an aim of achieving an optimal outcome. Case management seeks to increase the efficiency of how case-related information and activities are handled; it involves keeping detailed records about an instance and taking records through a defined path.

Establish a clear definition of a “case” for ONRR across all business functions and support case management from inception to closure, including centrally storing information, tracking actions, and resolving cases quickly and efficiently

Facilitate knowledge sharing across ONRR through the intelligent tagging and organization of cases based on defined criteria, enabling ONRR to quickly understand actions performed and decisions made and resulting in consistent decisions, answers, and solutions across the organization

Highlight unique relationships among cases to allow for a more comprehensive picture of industry actions and result in efficient analysis and delivery of outcomes

Business Need Through BPR, ONRR identified three significant opportunities that would be supported by an enterprise Case Management module. One recommendation focused on the expansion of its case management capabilities, the second spoke to the need to deploy and sustain a comprehensive compliance strategy, and the third targeted enhanced compliance planning. All three focus on improving the effectiveness of compliance activities as well as the management of all forms of internal and external interactions that a Case Management module would support.

In its documented To-Be state, many core business activities tie to lease reporting and associated compliance activities. These activities often build upon one another. As such, a Case Management module can provide the valuable links across activities so that users can understand the whole story of a lease. For example, the Identify Potential Case Assignment process may result in a flagged group of properties that appear to be under-reporting processed gas. Using a Case Management module, all information tied to compliance activities for this case would be centrally tracked, including documents, analyst notes, actions taken, and even records of analyst emails or phone calls.

Additionally, in the future, the definition of case and case types for ONRR will be broader – no longer just compliance reviews and audits – which means that a Case Management module would have an important supporting role in Collect to Disburse (e.g., invoicing, debt collection, and missing reports) as well as Report and Share (e.g., provide guidance, pull and share data) value chain primary activities in addition to Compliance. Case Management can be used to track issues with a lessee, operator, payor, property, or lease from reporting to enforcement or appeal.

As-Is Description ONRR has an existing custom case management system, the Operations Management Tool (OMT).

However, it is not widely deployed and does not provide complete case management functionality that can be scaled efficiently across ONRR. A by-product of the Compliance Business Plan, OMT tracks only the compliance lifecycle, including planning, execution, monitoring, and reporting of compliance processes.

• Track a case end-to-end (i.e. through appeals, settlements, or debt collection) management of non-deterministic business processes driven by events, rules, and human judgment

• Correspondence and collaboration with stakeholders to support case processing

• Management of unstructured content (documents, videos, etc.) and supporting metadata

• Advanced analytics for insights on case patterns and outcomes

• Correlation of case data to inform analytics and case collaboration

• Dynamic security models based on organization and case roles, case state and access controls at the case classification, record, or field level

• Provide a single tool for ONRR and STRAC to track and share their compliance work

• OMT does not provide read-only access

• OMT only tracks audit-related work items

(i.e., it tracks audit findings, orders, appeals but not finance, data mining, or other ONRR work items)

• Difficult to track down the previous work ONRR has completed in relation to a specific lease or company

• No centralized or consistent storage of case-related data or documents at the enterprise level (i.e., outside of OMT)

• Difficult for STRAC and ONRR to share information on past and current cases, specifically information outside OMT, or cases not stored in OMT

Implementation Considerations Historically, ONRR has only employed Case Management, through OMT, to support compliance activities. However, the future of ONRR entails establishing a clear definition of a “case” across all business functions to be able to share knowledge within the organization through the organized, relational, and central storing of information. In turn, the aggregation and analysis of this information – the case data – allows for ONRR to better identify both existing and potential issues and, subsequently, act both reactively and proactively. In this manner, Case Management becomes integral to each of ONRR’s value chains, not just Ensure Compliance. As such, it is essential that the Case Management module also integrate with all other modules, especially Financial Management, Customer Relationship Management, and Business Intelligence. Specific examples of points of integration are called out in the “Integration with Other Modules” table below.

Business Design Policies / Regulations Risks

All case types need to be clearly defined. Business process for each case type must be defined from initiation to resolution.

Functionality should support metrics-based reporting on case completion and case outcomes.

Policies must be updated to reflect new processes.

Design should consider GAO findings (May 2019) to strengthen compliance efforts.

Data migration from the old systems – including all case management systems currently in place such as CIM, OMT and offline databases – to the new system will need to be properly managed, including retention of legacy case data from prior systems.

Technical Design Execution Stakeholders

Many platform options exist for case management and workflow systems with cloud native solutions becoming increasingly more valuable as organizations adopt cloud platforms.

No single technology toolset will provide the entire solution and realistically will require the development and integration of multiple capabilities to be integrated such as CRM and BI at a minimum.

All stakeholders internal and external will be impacted (e.g., STRAC identified issues will inform case designation). Industry data requests will need to be tracked in the module. Internal roles and access will be needed across collect to disburse, compliance, and report and share business areas.).

Assumptions

• Policies will be updated to reflect new compliance processes.

• All business processes supported by Case Management will be fully automated in the module.

• A data model and supporting data structure for all case management data will be developed.

• Existing applications will be replaced with the new case management module implementation.

• Internal and external stakeholders will have access to the module appropriate to their role.

The Case Management module will need to be integrated with other modules to take a data-centric approach to automating processes. Overall, the Case Management module will integrate with the following functional modules to:

Business Intelligence Analyze trends and report on case data using the BI module

CRM Provide information on stakeholders and other data needed to track the entire case management workflow including all communication occurred

Data Management Share data bi-directionally to inform, update, and resolve case actions Financial Leverage financial reporting data to inform case actions as case actions may result in activities that would require financial data processing Mission Assist Desk Source “inquiry” cases that would need to be tracked and routed

Risk Analytics Inform the development and iterative updates to risk models based on case issues and outcomes. Risk models output will also inform case establishment

Self-Service Portal Enable Industry to submit and access case data

Customer Relationship Management

Overview Customer Relationship Management (CRM) improves an organization’s understanding of its stakeholders and allows it to actively manage and improve those relationships. CRM tracks interactions and captures data on contact information, relationships, and preferences of stakeholders. This information is analyzed and applied to other business data to support decision making in stakeholder-facing processes.

Enable ONRR to save time and improve communication consistency by identifying the correct point of contact for a given issue, understanding relationships to more accurately evaluate and achieve compliance, and tracking interactions to increase consistency in responding to inquiries

Improve industry stakeholders’ ability to comply with all applicable rules and regulations

Better manage relationships with all stakeholders who engage with ONRR at any point along the value chain

Business Need More than 3,000 industry stakeholders provide payments and reports for a variety of leases to ONRR each month. Many of these stakeholders fulfill different responsibilities on a lease-by-lease basis. These different roles can make it difficult to identify the correct point of contact when an issue arises. ONRR needs to better manage the life cycle of each lease by leveraging more robust information about its stakeholders and make it accessible to all support functions throughout the value chain.

As-Is Description ONRR lacks an enterprise-wide CRM. Today, industry information is captured at the user level via the External MRMSS Application Request Form (eMARF) for a company. While official correspondence information for reporters and payors is captured via Form 4444 and several ONRR programs have Access databases or Excel spreadsheets to track points of contact, there is no integrated system that manages stakeholder interaction for ONRR. Holistic management of relationships and tracking stakeholder interactions is not currently feasible.

• Manage roles and relationships among stakeholders and leases

• Track external stakeholder communications and interactions

• Push notifications to stakeholders when events or activities occur

• Store and update stakeholder information and make it available enterprise-wide

• Increase probability of compliance

• Difficult to identify the correct point of contact for companies on issue-by-issue basis

• Difficult to update stakeholder information

• Not all stakeholders are in the system

• Unclear stakeholder roles by lease

• Manual notification of activities

• Cannot determine if stakeholders are related

(e.g., parent and subsidiary)

• Multiple payor codes for some companies

Implementation Considerations CRM must integrate with the other functional modules. Quality data and the standardization of its entry are key to ensure that the CRM provides maximum value. ONRR has regulatory oversight and authority over industry; this is a different type of relationship than usually exists in CRM implementations.

Business Design Policies / Regulations Risks

Supporting processes, practices, and modules must be in place, including clear stakeholder identification. Any stakeholder that is a liable party on a lease may need to be tracked. Current laws and regulations do not support lease relationships and design will need to consider best approach for identifying and managing those relationships.

Royalty Simplification and Fairness Act (RSFA) laws should be reviewed, and a determination made if an update is needed. Currently, it does not support identifying contact and reporting responsibilities. Policies around Information Collection Request (ICR) will need to be updated to collect additional data that ONRR would want in its CRM.

ONRR must rely on stakeholders to keep their information up to date and accurate; if they don’t, the module functionality and value will be compromised and lead to rework and other inefficiencies that the module was intended to help avoid.

Technical Design Execution Stakeholders

Lease relationships may be difficult to codify. Business rules and processes need to be designed around who to contact for what activities, both official and informal contacts.

ONRR will need to select which stakeholder group to initially prioritize for rollout.

ONRR should ideally prioritize the lessee of record information that land office systems already contain.

ONRR will need to determine how to identify stakeholders and define and handle sub-groups. Internal and external users will be providing data captured in the CRM module.

Assumptions

• Stakeholders will frequently interact with the CRM to communicate with ONRR, view notifications, and keep their information up to date.

Integration with Other Modules

The CRM provides contact information necessary for external communications by ONRR programs. It also tracks interactions and makes this information available enterprise wide. The CRM module must integrate with other functional modules to facilitate information transfer and:

Business Intelligence Provide data for analysis and visualization

Case Management Provide information on stakeholders and track communication throughout a case

Data Management Store CRM data and interface with information from the other modules Financial Provide information on stakeholders, especially their role(s) on a lease to facilitate payment to receivable matching Mission Assist Desk Route questions and inquiries received from stakeholders, facilitate follow-up communication, and capture interactions Risk Analytics Provide information on stakeholders, especially their relationships with one another and role(s) on a lease to facilitate case identification Self-Service Portal Facilitate stakeholders’ communications with ONRR and update their information

Mission Assist Desk

Overview A centralized mission assist desk with tiered support is designed to funnel the majority of ONRR inquiries into one central location. This allows the mission assist desk operator to answer basic questions and to categorize and prioritize inquiries for routing to ONRR Subject Matter Experts (SME). It will move ONRR away from fielding inquiries in an ad-hoc manner and toward a streamlined, robust stakeholder support model.

Enable ONRR to better serve its stakeholders through standardizing and formalizing the process in which ONRR receives, tracks, and addresses internal and external inquiries

Provides centralized support, ensuring a consistent response to inquiries

Enable tiered support, allowing ONRR to prioritize its inquiries and more efficiently utilize ONRR resources to address the problem

Business Need ONRR does not have a centralized mission assist desk, thus its programs must field inquiries on an ad-hoc basis from internal and external stakeholders. A centralized ONRR mission assist desk will provide one point-of-contact (POC) for all ONRR stakeholders. The mission assist desk will operate under a tiered approach. The mission assist desk will have a dedicated operator (or group of operators) that acts as the initial POC for all ONRR inquiries. The operator(s) will field inquiries and provide basic (i.e., “Tier-1”) support (e.g., FAQs, directing stakeholders to ONRR.gov). If the inquiry requires subject matter expertise (i.e., “Tier-2” or higher), the operator(s) will refer to the appropriate ONRR SME to address the inquiry.

Additional functionality could allow for pre-screening of inquiries, using automated response functions prior to routing requests, while enabling call tracking. Providing support for internal ONRR employees will help ONRR best share and leverage the knowledge of its SMEs across the organization.

In addition to level of subject matter expertise required, the operator(s) will be responsible for triaging inquiries by level of importance. All inquiries and the related data, such as who is asking the inquiry, the type of inquiry, and whether it was referred to an ONRR SME, should be tracked and managed at the ONRR-wide level in the CRM and possibly case management. Standardizing this repository of information will give ONRR leadership insight into what types of inquiries are trending, and how ONRR can continuously improve its business to better and more proactively address these common needs.

As-Is Description Individual ONRR programs address stakeholder inquiries on an ad-hoc basis. Additionally, inquiries are not tracked at the enterprise-level, although some programs keep track on their own via system tools (e.g., IRQM), Microsoft Excel spreadsheets or Access databases.

• Centralized mission assist desk for internal and external inquiries

• Free up ONRR SME’s time from having to address ad-hoc inquiries

• Track inquiry-related metrics and information to continuously improve ONRR’s ability to serve stakeholders

• Provide a consistent and unified answer to similar questions and reduce “answer shopping”

• Lack of clarity for internal and external stakeholders on where to direct inquiries

• ONRR employees receive ad-hoc inquiries not directly related to their work requiring them to find the appropriate resource

• Difficult to identify correct program to address question

• Lessee(s) have no central point of contact withing ONRR or easy way to get to prior submitted information

• Lack of centralization can lead to ONRR providing inconsistent responses to inquiries

Implementation Considerations While a mission assist desk will not likely impact other ONRR processes, it will leverage information and require integration with other modules. Effective change management will be essential to the successful adoption and enhanced user experience that an enterprise-wide mission assist desk brings. Instances of industry reaching directly to an ONRR program SME will still exist. These instances will still need to be captured in ONRR’s larger repository of inquiry data as a reference for future mission assist desk queries.

Business Design Policies / Regulations Risks

The Handle Inquiries To-Be process will provide a foundation for the mission assist desk activities. Additionally, the mission assist desk is not anticipated to significantly impact other ONRR processes.

ONRR will need to define the different tiers for inquiry categorization and prioritization.

If ONRR stakeholders choose not to use the mission assist desk, it may prove burdensome to ONRR.

Technical Design Execution Stakeholders

The mission assist desk will likely leverage ONRR’s future CRM and/or case management solution to support the routing of questions and tracking of information. Automating routing and tracking functionality should be included.

The mission assist desk will require human resources dedicated to fielding inquiries.

ONRR will need to work closely with HR to identify and employ resources for the Mission assist Desk.

Stakeholders will face a learning curve in using a new system and process to communicate with ONRR. This will require a change management and communication strategy to reach all stakeholders

Assumptions

• ONRR will dedicate resources specifically to manage the mission assist desk.

• ONRR will implement new technologies to facilitate the routing of inquiries and capturing and tracking of inquiry-related information.

• ONRR will identify inquiry trends to continuously improve its service to its stakeholders.

The Mission Assist Desk module will likely integrate closely with the Self-Service Portal, Case Management, and CRM functional modules. These three functional modules will provide stakeholders with a mechanism to submit inquiries, enable ONRR to capture interactions with inquirers, and more efficiently track the lifecycle of inquiries (i.e., from submission to when the inquiry is closed). Overall, the Mission Assist Desk module will likely integrate with the following other modules to:

Business Intelligence Conduct trend analysis on inquiries to support continuous improvement Case Management Track and route inquiries

CRM Capture and track inquirer interactions and information (e.g., contact name, email address)

Data Management Help ensure data integrity for inquiry related information Financial N/A (Minimal to no integration)

Risk Analytics N/A (Minimal to no integration) Self-Service Portal Preferred interface for stakeholders to submit inquiries to ONRR

Business Intelligence

Overview The Business Intelligence (BI) module is software used to retrieve, analyze, and transform data into useful, tactical, and strategic business insights. BI software does more than present data, it allows users to interact with the data. BI software may include – or in the case of a Data Warehouse, rely on – the following functions and tools:

• Data Analytics – The process of deep analysis of data to find trends and answer questions with the goal of anticipating future demands.

• Data Mining – A process used to extract usable data from a larger set of raw data. The process of analyzing large amounts of data to find patterns, trends and associations that are not obvious. It informs methods of analysis that would otherwise not be effective with the amount and type of data usually presented with standard reporting. It aids predictive analyses and supports the initiation of a case or corrective action

• Data Visualization – The graphical representation of data for decision makers that involves producing images to communicate relationships among data.

• Data Dashboard – An information management tool that visually tracks, analyzes and displays key performance indicators (KPI), metrics, and key data points to monitor the health of a business, department, or specific process. Dashboards are customizable to meet the specific needs of stakeholders.

• Reporting – A presentation of data for a specific purpose.

• Data Warehouse – A centralized data repository using dimensional organization that is read-only to users, updated only by an automated (such as a daily) ETL (“extract, transform, load”) process from transactional data. This data facilitates structured, predetermined types of information through iterative “drill-down” queries.

Enable ONRR to make informed business decisions, maximizing the benefits of having validated data and a single source of truth that promotes trust and transparency with internal and external stakeholders

Provide a consistent interface that allows users to perform data analytics and reporting of operational and analytical data within the single source of truth, enhancing the ability to connect, analyze, and report on data across functional business areas

Business Need ONRR needs to leverage BI to select cases with the high probability of noncompliance findings and opportunities for payment collections (i.e., identify erroneous reporting, insufficient payments) because ONRR has limited resources and cannot currently conduct in-depth reviews of all properties for all reporting periods.

Currently, audits and compliance analysis are extremely time consuming, requiring the manual analysis of large amounts of data. Use of BI, specifically machine learning, would significantly improve the efficiency of compliance analysis.

ONRR has difficultly extracting summary data or providing a “general picture” of current activities. For example, ONRR leadership may request data on how many civil penalties have been issued for a specific category in the past 12 months. Analysts currently compile this data manually. Developing dashboards for these key metrics would provide instant oversight of current activities and status of key metrics.

A need for leveraging geographic information system (GIS) data across the organization also exists. Most BI tools include built-in GIS tools that provide a variety of maps with different options for data display.

For example, ONRR could overlay index price zones with markers for properties under compliance review and highlight a specific radius to illustrate the reasonable transportation distance around gas or processing plants.

As-Is Description Currently, ONRR does not have a holistic BI system. Rather, several disparate systems and tools are used for data mining and reporting, including MS Excel, MS Access, and Tableau. ONRR also has some highly customized tools with narrow functional focus:

• MRMSS Reporting and Analytical Tool (MART), built on Oracle Business Intelligence Enterprise Edition (OBIEE+)

• Information Request and Query Management Tool (IRQM)

• Royalty In Value Calculator Tool (RIVCT)

• Other custom and commercial off-the-shelf (COTS) data mining tools.

Today, ONRR lacks a “single source of truth” (SSoT) of data used for analytics and data availability is convoluted. Also, ONRR has not identified ONRR business rules for pulling data furthering the need for a SSoT. As a result, reports or queries are difficult to run, limited in scope, and can give erroneous information.

• All data used in analytics processing will reflect the “single source of truth”

• Stakeholders able to independently complete reporting tasks that currently require ONRR staff intervention

• Leverage advances in data science to perform predictive analysis, transforming ONRR from being reactive to proactive

• Analyze data across functional modules

• Increases the visibility and availability of data

• Stakeholders are able to create their own data reports and visualizations

• Provide a wide variety of preset visualization options

• No “single source of truth” in data used for analytics

• Poor data quality (e.g., outdated values, multiple values for one record, incomplete fields, overly complex data architecture)

• Offline data manipulation

• Lack of business metadata

• Lack of consistent business rules for pulling data

• Inconsistent data (table) structures require custom code to query or display

• Data queries are difficult to run or may return unexpected information due to underlying issues with data structure

• Users do not have role-based access required to query data they need

Implementation Considerations The BI module will need to be configured to access ONRR data. ONRR will need the right resources from a business and technical perspective to ensure the data is organized to meet business goals. Having a dedicated Data Warehouse of dimensional data is the foundation for BI. ONRR will need a strong data governance program that defines business rules for pulling data, integrating data, and visualizations.

Business Design Policies / Regulations Risks

The BI module can support and inform all parts of the value chain. ONRR must identify the key business goals of BI and design the module accordingly.

Policies will need to be developed to determine access rights to the data.

Concerns over flawed input data, poor data architecture, sufficiency of in-house data science skillsets, and long-term data management must be mitigated.

Technical Design Execution Stakeholders

ONRR will need to design the logical and physical architecture of the data as well as the ETL processes to populate the dimensional data. Role-based access needs should be well-established.

BI tools are only as good as the data they access. Focus must be to ensure new data validation processes work well and to improve the methods and quality of data transmission from sister agencies.

Users may find it difficult to reach the necessary level of competency with BI tools.

Competency requires learning how to get report data from the tool and how to usefully present and report information.

Assumptions

• There will be a data warehouse with validated data for the BI module to leverage.

• Internal and external stakeholders will have access to the BI module appropriate to their role.

The BI module will integrate with all the functional modules. It is dependent on a SSoT for data quality and it will connect, analyze, and report on data across the functional business areas. Overall, the BI module will integrate with the following functional modules to:

Case Management Analyze and report on case data and connect relationships and trends of cases to the other functional areas. Initiate a case based on BI findings.

CRM Analyze and report on stakeholder data and connect relationships and trends of stakeholders to the other functional areas

Data Management Leverage the data in the Data Management module. The tool will have access to operational data and dimensional data explicitly designed for analytics

Financial Analyze and report on financial data and connect relationships and trends of the financial data to the other functional areas

Mission Assist Desk Conduct trend analysis on inquiries to support continuous improvement Risk Analytics Use analytics and data science to implement the module goal of identifying potential compliance cases Self-Service Portal Give easy access to BI outputs (e.g., dashboards, visualizations and reports)

Risk Analytics

Overview The Risk Analytics module will support and drive compliance activities in the ONRR value chain. For example, the Identify Potential Case Assignment To-Be process will be informed by outputs from Risk Analytics. The purpose of Risk Analytics is to apply principles of analytics and data science to quantitatively identify potential compliance cases in support of compliance goals. Data-driven, mathematical models will provide the foundation of the Risk Analytics module, enabling ONRR to focus finite compliance resources to cases that have the highest likelihood of noncompliance findings.

Risk Analytics should be continuously improved, taking outcomes of past compliance activities to inform updates to underlying risk models. Its functionality will likely fit within the Business Intelligence platform, but the need and requirements for Risk Analytics models are significant and warrant inclusion here as a distinct functional module.

Provide a rigorous form of learning through data science and advanced risk models which ONRR can use to systematically identify compliance cases with the greatest risk of non-compliance, do so in a defensible, robust manner (not based solely on intuition), and generate a high return on investment (ROI)

Business Need This module is used solely in the Identify Potential Case Assignment To-Be process. It is a software application that selects compliance cases for the Analyze Case process. The module examines potential compliance cases, which consist of reported royalty and production data, and provides output that supports prioritization of or even explicitly prioritizes case assignments based on risk. Design and functionality of the Risk Analytics should enable ONRR to clearly answer why and how cases are selected for compliance activities, i.e., supporting recent recommendations of the U.S. Government Accountability Office (GAO).

A goal of Risk Analytics is to rank all potential case assignments based on risk and direct ONRR’s finite compliance resources to those cases that pose the greatest likelihood of noncompliance. Factors that influence risk could include time elapsed since last audit, company size, history of noncompliance, commodity type, payment amount or geographic location. Another goal is that the Risk Analytics module must provide transparency. Information emanating from Risk Analytics should clearly convey why something is risky or what makes up a particular risk score.

ONRR expertise will be needed to develop weighted risk algorithms. Then the risk tool will be dynamically updated, taking the results of each successive round of case analyses and using those results to improve the risk score algorithms. Artificial intelligence capabilities (such as machine learning) should be leveraged to support this capability and inform ONRR’s decisions. Data collected from reporting in the Financial module could also feed the risk analysis models.

As-Is Description ONRR previously developed a risk tool, but implementation of the tool was limited. This limitation stemmed partially from the fact that the singular model was not updated over time, which reduced its value and the relevance of its outputs. In addition, because a 3rd party vendor controlled the operations and maintenance of the prior risk tool, ONRR had minimal control and insight into how the tool was designed, built, and functioned to accommodate ONRR requested functionality.

• Provide greater transparency around why ONRR has identified an activity or activities as a risk and created a case

• Reduce the manual effort associated with identifying and “pre-analyzing” cases (i.e., manually analyzing potential cases to consider for compliance activities)

• Ensure that ONRR compliance resources are being directed to cases that have the highest likelihood of non-compliance findings, satisfying ONRR’s statutory requirement to provide high ROI of taxpayer dollars on compliance efforts

• Provide an unbiased and legally defensible means of identifying potential noncompliance through mathematical algorithms versus expert opinion

• Identify noncompliance issues that cannot be manually identified by ONRR analysts and can only be identified with the assistance of computational tools

• Provide more comprehensive case identification across industry stakeholders and resource types

• Manual effort and offline data processing (e.g., Excel) are used to identify cases

• Current case assignments are not optimized to review the riskiest cases

• Cannot view case results and systematically incorporate into analysis criteria for future assignments

• The audit manual allows for professional judgment in pursuing a case

• Auditor background research, while important, should not be part of determining whether an assigned case is worth pursuing, which takes time

• Lack of communication between work planning and compliance review teams results in work planning team receiving inconsistent data, inhibiting ability to optimize case assignment

• Unclear prioritization of clean data vs total collections

• Solids, geothermal, unbundling, and residency audits often require preliminary research when work planning does not identify (generate) cases for these types

Implementation Considerations Continuous improvement will be a complex but critical feature of Risk Analytics. Because mineral revenue reporting varies greatly over time, any models will need to adapt to be continuously updated in order to maintain relevance.

The Strategy and Analytics Office (SAO) will be the primary owner of Risk Analytics models and their design; however, the targeted future state of “comprehensive compliance” processes across ONRR will require input into Risk Analytics functionality from across program areas (e.g., financial, reference, enforcement). In addition, Risk Analytics will need direct feedback from closed compliance cases.

ONRR’s dedicated work planning group will be the primary user of the module. All users who do compliance case work (i.e., Analyze Case To-Be process) will work with cases that are outputs of Risk

Analytics module. Risk Analytics effectiveness will only be as good as the data collected and used to inform the underlying model or models.

Business Design Policies / Regulations Risks

Business expertise is needed to develop approach and algorithms that measure risk of noncompliance. At a minimum, ONRR will need to define risk and the factors that contribute to it.

Risk Analytics models would help ONRR comply with USC §1722 (g), which requires ONRR to only engage in audit and compliance activities if the expected collections are greater than the cost of conducting the activities.

If continuous improvement (i.e., updates to risk models, frequent refreshes of source data, and supporting algorithms) is not built into the module, its utility will degrade over time.

Technical Design Execution Stakeholders

Given the range of compliance issues, multiple risk models will need to be designed to support module functionality goals. Model design should leverage built-in statistical and analytical coding provided by selected statistical / BI platform package to minimize need for custom code.

The module and its models will require iterative updates to ensure it works effectively, requiring patience and ongoing training, testing, and validation of the model using ONRR data.

SAO will be the primary owner of the Risk Analytics models.

However, in the future state, “comprehensive compliance” means nearly all program areas will be stakeholders of the module. The work planning group will be the primary user of the module. All compliance case analysts will work cases identified by the Risk Analytics module.

Assumptions

• Data quality must be good for the risk models to be accurate and effective.

• ONRR has an expert understanding of what factors influence noncompliance.

• ONRR has data science resources to implement risk algorithms in line with compliance goals.

Risk Analytics highly depends on data gathered or hosted by several functional modules. Functionality of the module will likely be part of (built on or into) the future BI platform. Overall, Risk Analytics will likely integrate with the following other modules to:

Business Intelligence Leverage platform capabilities, as well as its outputs, to identify risks

Case Management Inform case identification for compliance activities CRM Support compliance case planning identified by the risk analysis model(s)

Data Management Access data…