B08_SOL_Attach_B_ACReS_PWS_MSP.pdf

Supplemental Performance Work Statement

Account Collections and Receivables System

(ACReS)

Mission Services Platform June 28, 2023

1. GENERAL INFORMATION.

1.1. Scope. This Performance Work Statement (PWS) provides for development with Operations and Maintenance (O&M) support for the Account Collections and Receivables System (ACReS) for the Bureau of Land Management (BLM) onto a centralized and common platform. The ACReS system will replace the current system named the Collections and Billings System (CBS).

1.2. ACReS Overview. The Bureau of Land Management’s (BLM), Division of Business Services (DBS), Accounting and Operations provide guidance and oversight of collections, deposits, billings, and reporting functions for amounts due the BLM from multiple BLM programs through CBS:

Manage more than one million collections and billing transactions for a monetary value of more than $1.8 billion annually.

Provide a secure financial system for collections and billings with program language capable of being scaled to communicate with multiple methods of mission point(s) of sale (POS) for eleven

(11) BLM program areas.

Ensuring data quality and policy adherence.

Interface with DOI’s Financial and Business Management System (FBMS) allowing the exchange and posting of collections information to the general ledger.

Provide reporting functionality for transactions within the system.

1.3. Business Need. CBS has been identified by the Department’s Office of the Corporate Information Officer as high risk of failure for the past three (3) consecutive years. The current system is unstable and unable to be enhanced due to legacy technology it was built on. If the system experiences a significant and/or unpredictable failure, the data within will become unrecoverable and BLM will no longer be capable of performing collection or billing transactions. BLM’s collection and billing supports and manages more than one million transactions for a monetary value of more than $1 billion dollars on average annually and provide a financial system for eleven (11) BLM program areas, twelve (12) state offices, fifty (50) district offices, and multiple field offices nationwide. CBS supports over 1,100 BLM employees as users and thousands of external customers.

1.4.

1.5. Government Points of Contact.

Senior Project Manager Name: TBD Email:

Phone:

Project Manager/Contracting Officer Representative Name: TBD Email:

Phone:

Product Manager Name: TBD Email:

Phone:

Contracting Officer Name: Cynthia Garrison Email: cynthia_c_garrison@ibc.doi.gov Phone: 703.964.8840

1.6. Travel. The service provider may be required to travel for the following:

1.6.1. One annual agile meeting in Denver, Colorado

1.6.2. In-person training at BLM State Offices prior to or mid-deployment

1.7. Period of Performance. Base one (1) year with four (4) year option periods.

2. DESCRIPTION OF SERVICES.

2.1. The SP shall support full development services as described by the Mission Services Platform (MSP) IDIQ terms and conditions for the ACReS Project. The following additional or supplemental terms also apply.

2.2. ACReS Documentation. BLM will provide the SP with existing ACReS documents during the Request for Quote (RFQ). These documents may be used to assist in accurate project definition and improve successful outcomes in development and platform/custom O&M support. The documents are current and considered reliable and should be used by the SP to improve planning and proper validation of requirements which must be completed and approved by the Product Owner (PO) prior to development.

2.3. Federal Resources Available for Development.

2.3.1. Product Management Team (PMT). The core members of this team will consist of a Contracting Officer (CO), Contracting Officer Representative (COR), Business Manager (BM), Project Manager (PM), and Product Owner (PO) (also referred to as Product Lead). The federal team will also allocate federal support in the area of GIS, Data, and Security. This support is intended to facilitate successful outcomes but should not be considered a substitute for necessary developer resources to complete successful development.

2.3.2. Integrated Product Team. BLM will also provide an Integrated Product Team (IPT) consisting of state representatives, stakeholders, User Acceptance Testing (UAT) members, and Subject Matter Experts (SME). It should be noted that this IPT is not considered to be fully allocated to the project. State representatives and stakeholders may be used as a resource to facilitate successful quarterly IP Sprint activities where identified. SME’s (full time or part time) can be provided as proposed to the project as needed based on the applicable stages of development but shall be identified and communicated to BLM early on by the Service Provider. The plan shall be updated upon completion of Validation and Planning and/or as changes in assumptions occur throughout development. Additionally, User Acceptance Testing (UAT) members may be allocated to support the User Acceptance Testing for each release (the team will identify the appropriate cadence for UAT during the Validation & Planning Phase). While the Service

Provider is responsible for developing training materials to support a Train-the-Trainer (TTT) approach, BLM will provide support to facilitate successful training. Proposal shall include this teaming arrangement.

2.4. Reporting. BLM has existing reports in OBIEE for the current ACReS. As the new system is developed, the SP shall be responsible for providing the OBIEE team with the data mapping from ACReS so the OBIEE team can maintain and support reporting requirements.

2.5. Data Migration. BLM will be responsible for source data quality and making the source data available to the SP in a format mutually agreed upon in the Validation & Planning phase. The legacy CBS system is a financial system and every penny and transaction must be accounted for during the data migration process. The current production system has over 200GB of financial data spanning over twenty years. The SP shall be responsible for migrating data from the legacy ACReS system within the overall agile development process. The SP shall be responsible for demonstrating proof of a successful data migration.

2.6. Validation and Planning. BLM HR policy currently requires employees to be onboarded before allowed access to BLM meeting facilities. Onboarding new contractor employees can take a significant amount of time. SP shall propose a plan for beginning initial performance of Validation and Planning around this constraint. As an example, proposing and providing local off-site meeting facilities (Denver area) to conduct Kick-Off meetings and/or provide virtual meeting and collaboration environments that do not require BLM resources could meet this requirement.

2.6.1. Per the terms and conditions of the MSP IDIQ, the SP will be responsible for delivering a product roadmap upon completion of the Validation and Planning period. This is a draft and does not necessarily represent a firm strategy or format we are committing to in the absence of upcoming Validation and Planning work and collaboration with our new development partners. Please review and consider in your proposal.

Note: this may be used as the basis for your proposal if considered valid.

2.6.1.1. SP shall include the concept of identifying Minimum Viable Data (MVD) that will allow BLM to plan for and coordinate data migration (basic concept included in draft), validation, clean-up and other data activities in parallel to ACReS product development.

2.6.1.2. SP shall identify external and/or legacy systems/entities interfaces and/or events required for successful ACReS development and deployment (External Dependencies). This will allow BLM to plan for and manage external work in corresponding requirements for external system change and/or interface in parallel with ACReS product development to reduce the risk of delays.

2.7. Customer Service

2.7.1. Service provider shall provide satisfactory customer service level to BLM’s customers. Service provider shall implement a customer satisfaction survey process. The survey format shall be provided by the Government and will be used to measure customer satisfaction on completed tickets and completed releases. Format and content of surveys are at the discretion of the Government. Surveys are required to be solicited from customer by Service Provider, between 30 and 40 calendar days following completion and close out of customer submitted ticket and for development efforts after each Release. Surveys shall be collected and customer satisfaction metrics reported to the PM/COR in monthly status report and meetings.

3. REPORTS, DATA, AND OTHER DELIVERABLES

3.1. Key General Deliverables Table

Title Delivery Schedule

Scheduled Maintenance Releases Quarterly at minimum; and as required to maintain system operations

Emergency/Patch Release As required; event driven

Weekly Status Report On day agreed to by COR/PM

Monthly Status Report including Performance Threshold Metrics

10th calendar day (may attach to invoice)

Product Roadmap and Release Plan with critical releases and milestones

Provided draft with proposal; finalized with completion of Validation and Planning; updated quarterly or as requested by the COR

Situation Report 5 business days following completion of O&M perfective ticket with variation of (+ or -) 10%

Security Assessments Annually and as required

Documentation Support Per table at 3.3.1.

Key personnel change request: Detailed explanation for substitution and resume

15 days from change; or notification 24 hours from trigger event when 15 day notification not possible

Risk Management Plan Provided 15 days following award ; reviewed/updated monthly

Quality Control Plan Provided 30 days following award; reviewed/updated annually

Analysis Reports As requested not to exceed 5 per year.

Styles Guide Upon completion of Validation and Planning, updated as required

System and Architecture Design Upon completion of Validation and Planning and updated if changes occur

Product Backlog Upon completion of Validation and Planning and updated continuously

Authorized Management and Supervisory List

No later than pre-performance conference and updated as changes occur

Accessibility Conformance Report Prior to deployment and updated on each major release at minimum

3.2. Deliverable Instructions

3.2.1. The BLM will review and approve and/or accept all deliverables. The Government will have up to 10 business days, unless specifically denoted below or extended by notification, to review each deliverable product and provide oral and written comments. The service provider shall review and incorporate comments or implement directed changes, after discussion or clarification from the PM and submit a final version of the product as required and specified and no later than 10 business days thereafter. Service provider shall facilitate effective communications to avoid delay in approving deliverables.

3.3. Release Documentation Requirements

3.3.1. The service provider shall provide version control for information, documents, software, hardware and other services provided to customers in order to ensure that users are provided correct and current information. The service provider shall ensure that their staff is consistent with information they provide for solutions or in general. The Service Provider shall comply with NOC-DIRM-ST-003 Quality Standards for Operational Acceptance in providing release support and documentation for the Operational Acceptance Board. The Service Provider may propose alternatives to some documentation based on the agile methodology proposed. Details about release documentation requirements are listed below by release types (unless reduced in writing by the COR):

3.3.2.

Update Frequency

Document Type

W/ Initial and Major

W/ Minor W/ Emergency COR Request or Annually Minimum

System Requirements Specification (SRS) X U U

Interface Requirements Specifications (IRS) X U

Software Design Document (SDD) X U U

Data Management Plan (DMP) & Data Dictionary X U

Requirements Traceability Matrix (RTM) X U

Computer Systems Operating Manual (CSOM) X U U

Operational Baseline Release Reports (OBRR) X X X

Test Baseline Release Reports (TBRR) X X X

Version Description Document (VDD) X U

FQT Test Plans X U

FQT Test Results X U

Request For Change (RFC) X X X

System & Requirements Analysis and Impact Analysis X

Software Development Plan X

System Security Plan (SSP) & Security Impact Assessment (SIA)

X

Technical Vulnerability Assessments X

Risk Management Plan X

Privacy Impact Notice X

Privacy Impact Assessment (PIA) X

Business Impact Assessments (BIA) X

System of Records Notice (SORN) X

IT Contingency Plan inputs X

Object and Source Code X X X X

Training Guide/User Guide/Manuals/Materials X X U X

Entity Relationship Diagram (ERD) X X X X

Release Notes X

X = Resubmissions of full document

U = Updates to last Major Submission

4. REPORTS, DATA, AND OTHER DELIVERABLES

Performance Metric Performance Standard AQL

System Availability

Does not include downtime for:

1. COR advanced approval

2. Infrastructure, operational or network issues beyond service provider control

System available for use in production environment

Note: Business hours of operation shall be considered Mon-Fri 6:00am to 6:00pm for application specific customer for this metric. Nationally used applications will account for these business hours for all user time zones.

Business: >98% system uptime per month in minutes (e.g. 12 business hour downtime in a 20 business day month = 13,680/14,400 or 95%)

Total: >95%system uptime per month in minutes (e.g. 24 hour total downtime in a 30 day month = 41,760/43,200 or 97%)

Note: For Satisfactory performance both “business” and “total” thresholds must be met.

Customer Satisfaction Customers are satisfied with service provided

Note: On a multiple question survey, any customer survey question rated Unsatisfactory shall render entire survey as Unsatisfactory for this metric.

>95% of all customer surveys returned are rated Satisfactory or better as measured per month.

Measured as the total number of customer submitted surveys rated as Satisfactory or better divided by the total number of customer submitted surveys for completed tickets or releases.

Documentation Deliverables Documentation deliverables are provided on schedule and meet format and content requirement of task order.

>95% of all documentation deliverables are provided on schedule as measured monthly or per release if no monthly deliverables are due. (total deliverables on schedule/total document deliverables due).

Other Perfective Maintenance Cost Control

The Service Provider shall estimate accurately tickets completed.

Note: Excludes tickets completed under budget where COR/PM validates Service Provider identified efficiency not known prior to estimation, and which was executed to the Government's benefit.

Satisfactory: 90% of tickets completed within (+ or -) 10% of estimate

(e.g. 9 tickets completed (+ or -) of estimate/10 total tickets completed = 90%)

Quality of Development The Service Provider shall maintain the proposed Development Efficiency Factor throughout development.

Satisfactory: Remediation ratio is not exceeded by more than 5% as measured cumulatively for the previous one year of performance. (e.g. if 30% is proposed then it shall not go above 35% to remain satisfactory) Ratio is calculated by dividing the amount of remediation completed in the previous year of performance into total development completed in that same period of time as measured using story points or other agile method.

Product Roadmap and Release Plan Accuracy

The Service Provider develops and maintains quality release planning as proposed and adjusted over time.

Satisfactory: Established release schedule is accurate within the plans stated range of variance and identified assumptions. The plans variance is attributable to identifiable changing assumptions and changing requirements as measured using this contract. Defined ticket categorization requirements.

Plan is updated at least quarterly.

Sprint Success Provide consistent and repeatable sprint completion rate with the goal of increasing velocity and improving efficiency over time. The Service Provider shall successfully deliver each sprint as defined and approved in each sprint planning session.

Satisfactory: At least 90% of sprint goals are achieved (meeting the definition of done or acceptance criteria) as measured using a 5 sprint sliding scale. This metric shall be measured using story points or other agile methods. Higher CPARS performance can be obtained with greater efficiency in obtaining sprint goals, increased velocity, or proven efficiency or velocity increase over time.

Attachments

1. Concept of Operations

2. Business Requirements Document

3. Business Requirements Matrix

4. Use Cases

5. User Stories

ACCOUNT COLLECTIONS AND

RECEIVABLES SYSTEM (ACReS)

CONCEPT OF OPERATIONS

Version Number: 1.0 Version Date: 12/06/22

Accounts Collections and Receivables System

ACReS Concept of Operations Page 2 of 26

VERSION HISTORY

Version Number

Author Revision Date

Description of Change

Version 1.0 S. Marquez, G. Woody 12/06/22 Initial release Version 1.1 B. Huerta 11/16/23 Minor revisions

Accounts Collections and Receivables System

ACReS Concept of Operations Page 3 of 26

Table of Contents Section Page

Contents Table of Contents Acronym List Project Overview 1 Introduction 2 Document Purpose 3 Document References and Information 4 Brief Overview 5 Business Need – Current Situation 6 Scope of Project 7 Concept for the Proposed Accounts Collections and Receivables System

7.1 ACReS Operational Overview

7.2 Operations and Support

7.2.1 Technical

7.2.2 Training and Education

7.3 New Opportunities and Capabilities Provided by ACReS

7.3.1 High-level Business Benefits (Value Proposition)

7.4 Rules Engine

7.5 Current Limitations and Constraints

8 ConOps Reference Material

8.1 Components

8.1.1 Program Resource Systems

8.1.2 IPAC

8.1.3 External Interfaces - Pay.gov, Vantiv Bank

8.1.4 CSA and WBS

8.2 ACReS Workflow

8.2.1 Workflow and Workflow Stages

8.2.2 Example User Workflow

8.2.3 Example Interface Workflow

8.3 Technology & System Functionality Definitions

8.3.1 Notifications and Reminders

8.3.2 Roles

8.3.3 Business Rules

8.3.4 Data Validation

Accounts Collections and Receivables System Concept of Operations

ACReS Concept of Operations Page 4 of 26

8.3.5 Rules-Based Workflow Engine

8.3.6 Real-Time Processing

8.3.7 Enterprise Reporting

8.4 ACReS Data, Security, and Compliance

8.4.1 Data Architecture/Reporting

8.4.2 Infrastructure Considerations

8.4.3 Security

8.4.4 Section 508 Compliance

8.4.5 User Experience – Accommodation and Design

9 Summary of Impacts

9.1 Migration to Platform-based Model

9.1.1 Training Plan and User Specific Guidance

9.2 Organizational Change

9.3 Data Migration

9.4 Helpdesk/Expert User Support

9.4.1 Online Resources

9.5 Specific NOC Considerations

10 Glossary 11 Sign Off: Concept of Operations Approval ......................................... Error! Bookmark not defined.

ACReS Concept of Operations Page 5 of 26

Acronym List

Acronym Definition A/R Accounts Receivable

API Application Programming Interface

ACReS Account Collections and Receivable System

BLM Bureau of Land Management

CBS Collections and Billings System

CIR Collections Information Repository

COTS Commercial Off the Shelf

CSA Commodity, Subject Action

DOI Department of the Interior

ESB Enterprise Service Bus

ETL Extract, Transform, Load

FBMS Financial Business and Management System

IPAC Interdepartmental Payments and Collections

MLRS Mineral and Land Records System

NOC National Operations Center

RMP Resource Management Plan

SDP Service Design Package

SME Subject Matter Expert

WBS Work Breakdown Structure

References to “Programs”, “Resource Systems” and “Program Systems” refer to BLM systems that interact or rely on CBS for a particular A/R function or service, which includes receiving and recording revenue, generating a bill or invoice, and creating receivables records. As used herein, Program Systems refer to systems such as MLRS (which encapsulates several resource systems including Alaska Land Information System (ALIS), Mining Claims (MC), Legacy Rehost (LR2000)), and Recreation Management Information System (RMIS) to name a few.

Project Overview Concept of Operations (ConOps):

Account Collections and Receivables System (ACReS) for the Bureau of Land Management

(BLM)

ACReS Concept of Operations Page 6 of 26

1 Introduction

The Concept of Operations (ConOps) is the culmination of research and analysis performed intermittently over several years on the BLM’s Collections and Billing System (CBS). It explains the purpose of CBS and justification for its modernization.

CBS’ main objective is to function as the System of Record1 for tracking money owed the BLM, including issuing of bills, and collecting funds due the BLM in compliance with regulation. The system will be used to manage billing for uses of public lands and services provided by BLM, account for revenue, update payment records, assess payment penalties, and issue invoices as needed.

On a daily basis, CBS manages all open accounts, calculates penalties and interest, reconciles receivables with Pay.gov and Vantiv Bank, and is the BLM’s interface with FBMS. Although FBMS is the DOI’s official System of Record, CBS contains detailed billing information that is not available in any other BLM system. Although quite robust, at its core, CBS is an accounts receivable (A/R) system.

Having been implemented in 1999, developed in software that is not used in other BLM systems, and not receiving routine updates, the time is long overdue for CBS to be modernized.

The new A/R system must fulfill the purpose of, and faithfully support, the existing requirements of the current system that is being replaced. It must also adhere to regulatory compliance for the billing of public lands and services provided by the BLM.

The Accounts Collections and Receivables System (ACReS) is the proposed replacement for CBS with the primary goal to deliver improved technology, functionality, extensibility, and support by utilizing a modern technology solution.

2 Document Purpose

The Objective of this document is to articulate the future vision for the modernized CBS system and business processes, from a user’s perspective, and provide high-level benefits and capabilities intended for the business as a result of this modernization effort.

A/R System usage and functionality is described primarily from a purpose and operational perspective by walking through how this system will address and accomplish the requisite tasks in being the system of record for all money due to the BLM by tracking accounts receivable, issue bills, and assess penalties for the BLM’s various Programs. It also provides the context in which this system must function and where it will need to be extensible to accommodate future business needs.

These details, descriptions and context together form the overall concepts of the future system, such that – along with the Business Case and Mission Needs Statement, Transition Strategy, and Service Design Package (SDP) documents – prospective vendors and system integrators will be

1 A SORN is currently sought to identify ACReS as a formal System of Record.

ACReS Concept of Operations Page 7 of 26 able to thoroughly understand BLM’s needs sufficient to confidently provide a comprehensive and accurate proposal for providing a robust A/R system for the BLM. These proposals could include any combination of building, buying, customizing, and/or configuring various technologies towards satisfying the BLM and the needs of each of its stakeholder groups.

The document will also hold value in describing ACReS to selected users and stakeholders of the system.

3 Document References and Information

Content within this artifact is a result of Subject Matter Experts (SMEs), Stakeholders, and project Core Team members working together as follows:

• Documenting the current-state system by creating Use Cases, workflow and interface diagrams, and business requirements, which occurred from 2016 to 2018.

• Six workshops were conducted in Q1-2022, where requirements were reviewed for accuracy by business and technical SMEs to reflect subsequent changes in the CBS operational environment.

• Interviews and workshops attended by SMEs knowledgeable in all facets of CBS, including perspectives of frontline users, program users, and technical development and support.

Details amassed during the 2016-2018 activities, plus updates made since 2020, address what, why, and how users perform their work, the Programs and systems that currently interact with CBS, the challenges of today’s technical environments, features and functionality lacking in CBS but necessary for today’s business processes.

4 Brief Overview

The BLM currently uses the Collections and Billing System for a multitude of services, with focus on generating bills and invoices, tracking revenue and receivables, and collecting monies due for all revenue-generating Programs. Examples of such include sales from BLM Public Rooms and retail locations, national parks, and eCommerce websites. The fundamental purpose of CBS has been to serve as the system of record for tracking all revenue owed the BLM in addition to being the front-end accounts receivable system for the Department of the Interior’s Financial Business and Management System (FBMS).

CBS was developed in the late 1990’s using Panther, an aging technology owned by Prolifics. In 2010 it was determined that CBS, in its current configuration and architecture, was struggling to support the ever-growing demands placed on it by newer and expanding programs. An effort was initiated at that time to identify and evaluate solutions and architectures that would satisfy the original requirement defined by business users, as well as new requirements.

This ACReS ConOps represents a fundamental change from the current CBS design, functionality, architecture and platform to provide efficiencies in managing revenue and ensuring this system’s operational stability and ability to grow by incorporating state-of-the-art technologies:

• ACReS will sit on the BLM’s Mission Services platform that is managed by personnel having the requisite knowledge and skill set to support it

• As new systems are implemented that generate or collect monies, they can readily interface

ACReS Concept of Operations Page 8 of 26 with ACReS due to its running on a standardized and well-understood platform

• Functionality will be backward compatible to ensure existing systems that rely on communicating with CBS will continue to enjoy that relationship

There are several key drivers behind the need to improve and extend how the BLM’s A/R system functions and interacts with other BLM Programs and systems, which are covered throughout this ConOps. At a high level, they include:

• Implementing a Modern, Consistent and Extensible Technology Solution As more BLM revenue-generating Programs have launched over the years, they have their own unique A/R system requirements. This has resulted in systems being one-offs, where specific processing was added to CBS for that new system.

Many of the systems that interact with CBS submit their data via SFTP processes, delivering flat files that require specific validation tasks to ensure accurate formatting and content.

These flat files are not consistent, requiring CBS to have a multitude of validation instructions. Although ACReS must continue to support the methods used by those systems to accept their input, as a modernized system sitting on an Enterprise Service Bus, it will be easily modified to support those systems as their own data delivery capabilities mature.

• Migrating to an Enterprise Platform CBS is a standalone application running on an Informix database somewhat isolated from other systems with connectivity being added by leveraging older technology. Placing ACReS on a modern platform will provide extensive capabilities, such as utilizing web services and APIs and ease of establishing communications with other systems sitting on the platform.

ACReS will be able to take advantage of the platform’s Enterprise Service Bus (ESB), further improving interactions with other BLM systems.

• Improving Business Logic in a Business Rules Engine CBS was originally designed to incorporate business rules and accounting Work Breakdown Structures (WBS) in the form of CSAs (Commodity Subject, Action), providing a path for users who are not accountants to perform accounting functions. See Section 8.1.4 for a more detailed explanation of CSAs. ACReS will continue to use CSAs as business rules and logic-driven crosswalks to ensure accounts receivable accuracy, such as referencing the correct fund and GL accounts. The platform will extend rules functionality to services offered via APIs that will perform data validations before data reaches ACReS, helping ensure the integrity of that information.

• Ensuring Reliable Data

Currently, CBS relies extensively on data validation enforcement. This applies to manual data entry and to data input via interfaces. There are many aspects of data validation activities that ensure data entered is complete, accurate, and contains requisite values.

ACReS will continue incorporating these data validation processes. Unlike CBS, which is itself responsible for managing the data validation requirements for every interfaced system, ACReS will utilize web services and APIs that are responsible for their respective interfaced systems. Whereas CBS, in some situations, initiates an email or other communication to staff to manually correct the invalid data, the various APIs will assume that responsibility and allow ACReS to focus on processing clean data. While leveraging a more modern platform for the BLM’s A/R system cannot replace every manual workflow, a modern platform will automate a significant portion of the manual processes and workflows.

ACReS Concept of Operations Page 9 of 26

• Providing Robust Customer Relationship Management and Communications CBS lacks a formal, rigidly structured Customer Relationship Management database (CRM).

Although it houses customer details, there are no standard normalization rules. Inefficiency exists in numerous ways, including allowing multiple records for the same customer and lacking safeguards to prevent one BLM office from modifying another BLM office’s customer record. ACReS will be designed to leverage a standardized and administered CRM database that is shared among other BLM entities.

5 Business Need – Current Situation

CBS has reached and surpassed its end of life. To put this into context, the following aspects must be considered:

• Database: CBS runs on an Informix database. As of March 2022, Informix ranks 33rd among all databases, and 19th among Relational databases (db-engines.com)

• Technology: In order to maintain CBS and add new systems over the years, Panther (the primary CBS programming language), as well as the entire software stack, has mutated over the past twenty years. As new client systems connect to CBS, the latest tech is used, resulting in a lack of technical consistency between client systems. It is estimated that CBS is comprised of, at least, a dozen different technologies.

Risks associated with these considerations:

• Database: The large portion of the databases in place at the BLM are SQL or Oracle databases. Moving the underlying A/R system database to an environment more readily supported by the BLM will reduce the amount of resource overhead managing a non-standard database and increase the ability for more streamlined sharing of data.

• Technology: Due to the conglomeration of languages and years of functionality alterations, it is extremely difficult, if not impossible, to identify a single person or company that knows all these components in order to support CBS. The opportunity presented by building ACReS on a modern platform allows for more long-term support and extensibility than is currently available for CBS.

The greatest risk is that, if CBS fails, there will be a significant disruption to current A/R processes and workflows at the BLM with cascading negative impacts to FBMS and the DOI accountants who rely heavily on the information supplied by CBS.

6 Scope of Project

The scope of the project is to deliver to the BLM a robust billing and collections services system that provides consistent, uniform and efficient operations, built on an extensible foundation that will provide the ability to readily integrate future functionality and technology.

It should be noted that simply upgrading or reconstructing CBS in its existing format is neither an efficient nor economical option. CBS is comprised of numerous components and software languages, an aging database, and no coherent roadmap that explains all its architecture. The matter of upgrading the database versus replacing the front end, or vice versa, still brings in to question its ability to grow without a complete overhaul. This is further exacerbated due to the lack of quality documentation which causes difficulties for developers to add functions to support newer systems.

ACReS Concept of Operations Page 10 of 26

Included in this ConOps are details for training, educational materials, data retention, and migration options.

ACReS will receive numerous benefits including a service bus, which will provide a readily extensible environment to maintain pace as new Program systems come online.

ACReS will incorporate in-line business rules and data validation that will ensure data and business process integrity. It will be built on a modern and extensible data architecture that will leverage reporting capabilities already existing in the BLM infrastructure. As such, ACReS will not be required to implement one-off processes each time a new Program, system or product is introduced. The incorporation of web services and APIs on the BLM’s backbone architecture will alleviate the need for continual customization. As with CBS, ACReS will have configurable business rules and workflow definitions, with the workflow capable of seamlessly accommodating exceptions.

Project scope includes refining the processes and requirements artifacts created from previous analysis efforts needed to deliver a highly functional replacement for CBS. Business, Program, Stakeholder, Technical, and frontline users are participating in the preparation of all requisite artifacts. These will be used to develop material suitable for internal resources and external providers to understand the need and develop ROMs.

Overall, the scope is to apply all of CBS’ requirements into the new system, configure all current CBS interfaces, add web services and APIs, and produce quality training material.

7 Concept for the Proposed Accounts Collections and Receivables System

It is important to reiterate that ACReS is the modernization of the aging CBS application rather than a completely new concept. There will be improvements in efficiencies, backend processing, and extensibility. However, the core purpose of CBS remains the same with ACReS – that is, ACReS will be the BLM’s revenue and accounts receivable system, and frontend to FBMS. As such, the fundamental concept is to replace CBS with a technologically advanced application before CBS experiences operational failure.

Factors taken into consideration include potentially leveraging the existing Mission Services platform and service bus, minimizing user operational impact and ensuring all systems that rely on, or communicate with, CBS continue to be supported by the new ACReS.

7.1 ACReS Operational Overview

The future state of BLM ACReS operational capabilities will employ the advances in technological development, customer management strategies, data management practices, and future business operating models.

Although the purpose of ACReS remains the same as CBS, i.e.: manage billings, receivables, revenue collection, eCommerce, perform reconciliations and transfers between funds, several of the methods employed will be dramatically improved with modernized architecture. By residing

ACReS Concept of Operations Page 11 of 26 on a modern platform, ACReS will utilize its enterprise service bus to exchange data with those current and future systems that can take advantage of APIs and web services.

ACReS will continue to interface with legacy systems (e.g.: TSIS) and incorporate CBS’ BX Interface, which will support the needs of MLRS. It will furthermore realize a more efficient process for connecting with new Program systems as they are brought online.

ACReS will be much more than simply an accounts receivable system. In addition to billing and collection functions, ACReS will process IPACs and interface directly with external government systems such as Pay.gov and Treasury.

• The Pay.gov interface will provide several services to ACReS including credit card charges, verification, and authentication in real time. A nightly batch process will be received from Pay.gov for the posting of monies collected online from various BLM-related websites and sent to ACReS as paid revenue, and monies charged at BLM offices (e.g.: public rooms) and park entrances using Pay.gov.

• In the event Pay.gov is superseded by OTCnet (the Treasury/Fiscal Service solution for Deposit Processing and Reporting, Check Capture, Card Processing, etc.), ACReS will be more easily configurable to a new interface.

• Treasury provides a file (CIR) to federal agencies with information on deposits and collections. At present, the CIR file is manually pulled and inserted into Oracle as an XML file, then Informatica loads the data into CBS. ACReS will be able to leverage platform functionality to automate this process.

• CBS receives a nightly file from Vantiv Bank which contains transaction details that CBS ingests and uses for reconciliation purposes. It is estimated that this file will be replaced by the Treasury’s CIR file in the 2022 fiscal year and leverage automated functionality to transfer the data into ACReS.

To interact successfully with FBMS, the two systems must remain in sync. FBMS will provide updates to ACReS on a nightly basis that include details like available funds, fund balances, and GL accounts.

ACReS will take advantage of the BLM’s managed customer relationship management (CRM) database, unlike CBS, which manages CRM data without implicit operating rules that result in incorrect customer contact details.

ACReS will extend and enhance its information service model by providing real-time data exchanges with Program, resource, and other systems via web services and APIs using an enterprise service bus.

As some resource systems require the generation of a receivable (e.g.: via the sale of an item or contractual lease for land usage), billing details will be submitted to ACReS which, in turn, will validate the billing data and generate a unique ID number, typically referred to as an Authorization Number. ACReS will return the authorization number to the system originating the A/R to keep the two systems in sync.

For the full spectrum of ACReS functionality, refer to the Use Cases, User Stories, and Requirements Traceability Matrix.

7.2 Operations and Support

ACReS Concept of Operations Page 12 of 26

7.2.1 Technical

Operations and Maintenance (O&M) activities for ACReS will be performed by BLM infrastructure teams supporting the platform rather than relying on CBS-specific Technical Staff.

Certain actions taken in CBS, such as approving and entering a CSA, are performed by the National Operations Center (NOC). This responsibility will likely continue to fall upon the NOC, who will participate in training relevant to its responsibilities.

7.2.2 Training and Education

ACReS will maintain the purpose and operational processing to perform all requisite steps as currently performed by CBS. Although internal functionality may change, such as managing how content is handled by the user interface, the content itself will be the same as users are accustomed to seeing, resulting in a shallow learning curve.

Documentation in the way of user guides and technical manuals will be developed, along with any training delivery methods deemed appropriate by CBS stakeholders.

To further assist with training and maintaining a shallow learning curve, opportunities for new training roles can be introduced.

BLM Training Specialist

The Training Specialist role will be responsible for working with Program Managers to define and manage the development of the ACReS Supporting Documentation that will be available to all ACReS users to consult when needed. This documentation includes, but is not limited to, the Training Courseware, User Guides, System Documentation, Tutorials, How-To Videos, and Online Help materials. Members of this role will also be responsible for engaging in train-the-trainer activities to support the ACReS Trainers. They may also monitor all ACReS feedback channels for users’ experiences, requests, and suggestions regarding Supporting Documentation materials as part of continual improvement and keeping the material relevant and fresh.

ACReS Trainer Employees assigned to the ACReS Trainer role will be responsible for scheduling and providing training on ACReS usage and any other related courseware that the BLM Training Specialist and ACReS Program Managers have developed. They may be tasked with courseware and documentation development efforts as well.

7.3 New Opportunities and Capabilities Provided by ACReS

ACReS will benefit greatly from new technology. By having a single, cohesive software and architecture, speed to market will be greatly increased as new systems pose new requirements on ACReS. By leveraging the enterprise service bus, ACReS will continue to support those older interface methods and batch processing while also developing web services and APIs that newer Program systems can utilize. As those legacy systems are eventually upgraded or integrated into other systems to take advantage of API services, ACReS will already have those services in place.

ACReS Concept of Operations Page 13 of 26

Several aspects of CBS require hands-on tasks, such as making corrections to data, or manual intervention when an IPAC validation fails. Although current business process may continue to rely on manual intervention for the foreseeable future, ACReS will be easily updated to reduce or remove reliance on such support once the corresponding system takes advantage of the APIs.

New systems coming on board at BLM can subscribe to ACReS’ web services for billing and collections, rather than wait for new programming support to be added as is the current case.

Online Bill Pay will be a component of ACReS. This process will have the ability to benefit from having its own API and connect directly to ACReS.

7.3.1 High-level Business Benefits (Value Proposition)

Benefits the business will realize with the modernization of the CBS system and the transformation of its business processes include:

• Real-time billing – For those program systems that can take advantage of real-time billing, such as MLRS, a key benefit is in the ability to immediately know the billing status. This will be a significant shift for the BLM which will require programs to make changes in how they interact with the customers.

• An integrated enterprise customer model for the new CBS with, at a minimum, the WO 300 programs and potentially all BLM customers with accounts.

• Actual records management which should preclude extraneous creation and filing of papers and records schedule will guide the database record retention strategies.

• Real time payment status. ACReS provides service for programs to tap into the current state of the payment for an order, case, etc. This provides efficiencies for the ACReS user as well as adding benefits to program system users. Additionally, this functionality benefits the interface development and avoids data asymmetry problems, such as stale data.

• As BLM resource systems mature the management of case file documents and information, the ACReS system will be able to track supporting documentation to aid in processing of accounts and billing, as well as relevant supporting information.

• Incorporate improved functionality for interfacing with Pay.Gov including credit card processing and automated reconciliation.

• Automate the user and electronic interface workflows to reduce manual interactions and potential risks.

• Configurable and automated notifications to external users pertaining to their particular collections and billings interests.

7.4 Rules Engine

The ACReS Rules Engine will provide workflow functionality that manages and processes business rules that in turn will ensure accuracy and compliance with Program systems that

ACReS Concept of Operations Page 14 of 26 subscribe to ACReS for billings and collections functions, FBMS requirements, A/R standards, and BLM Policy. The rules engine will be based on CSAs, WBS (Work Breakdown Structure), and crosswalks. It will further control the user interface, fields, and field content available to users based on the activity being performed.

7.5 Current Limitations and Constraints

Since ACReS is replacing CBS, it is subject to all operational limitations and constraints currently placed on CBS. However minimal, any such limitations are identified in the ACReS Requirements Matrix.

An example limitation is ACReS must sit behind the BLM firewall and can have no outward-facing capabilities.

An example constraint is ACReS’ adherence to existing rules for interfacing with FBMS.

8 ConOps Reference Material

8.1 Components

This section contains explanations of the key phrases and language used in this document and is broken out by category for easier reference.

8.1.1 Program Resource Systems

Some Programs, such as Realty Billing, Timber Sales, and Mining Claims, generate revenue in the course of doing business. These systems will rely on ACReS to perform all facets of the billing and collection process. Some of these systems currently interface electronically with CBS and will continue to do so with ACReS. Other systems have traditionally relied on dual data entry, where the user enters Program-specific details into their Program system, then must also access CBS to create an A/R record, generate the bill, and eventually collect the receivables.

Suggesting changes to the methods of how those Program systems will interface with ACReS is not within this project’s scope. It is important to note that ACReS will continue to support the current communication methods used by each Program system. Those Program systems' communications methods evolve and can take advantage of ACReS services.

8.1.2 IPAC

Interdepartmental Payments and Collections (IPAC) is the process of moving money between federal agencies. The process for creating and transferring IPACs is a combination of manual, paper-based workflows combined with leveraging existing electronic processes in CBS.

IPACs are generally initiated in CBS, which uploads details to FBMS via the IF113 FBMS interface.

FBMS then transmits the IPAC to Treasury for processing. Treasury moves the appropriate monies from BLM to the given federal agency and communicates the confirmation data back to FBMS, which then sends this confirmation data back to CBS through the Data Exchange Server.

While this process will be carried over to ACReS, opportunities to leverage automation and electronic document workflows on a platform level will be implemented to reduce or eliminate current manual paper-based processes.

ACReS Concept of Operations Page 15 of 26

8.1.3 External Interfaces - Pay.gov, Vantiv Bank

Pay.gov is the Treasury Department service used to authorize credit cards and ACH transactions.

There are several ways Pay.gov receives money, including from BLM websites (e.g.: camping permits) and entered by BLM personnel at branch offices. ACReS will receive a nightly file from Pay.gov with the payment details from that day’s business and will create corresponding revenue and collections records.

Vantiv Bank is contracted by the Federal Government to settle credit card and other payments. It will send a nightly file to ACReS, which then performs reconciliations between the bank’s data and existing ACReS A/R records.

The nightly Vantiv Bank processing will soon be replaced by the CIR file, which will be pulled from Treasury and loaded into ACReS.

8.1.4 CSA and WBS

CSAP (commonly referred to simply as “CSA”) is a hierarchical structure used to categorize goods and services provided by the BLM and to ensure accurate alignment with corresponding accounting details.

Due to its critical nature, the CSA is defined as follows:

• CSAP: Commodity, Subject, Action, Product.

• GL accounting data is associated with a CSA code. Including the “P” in CSAP indicates a

Product level has been included with the CSA. An example of a Product is a topological map sold over the counter through a BLM Public Room.

• A CSA drives what fields are displayed on CBS screens and what data are provided or required for anything to do with a specific Fund. It is essentially used to perform lookups to understand what/how to process an action.

• A CSA can have multiple WBS’s.

• The CSA ensures that all necessary accounting data is entered at the time a transaction is created (e.g.: a functional area can use a particular Fund).

• CSA allows field office users to efficiently process transactions by picking a CSA based on the business activity rather than having to know the values for all the accounting elements involved.

• The CSA determines collection tasks, e.g., whether it should generate Collection Bills or Courtesy Statements or both.

• Crosswalk tables contain an “Action” code (from a CSA), which it uses to look up additional details.

• A crosswalk can contain multiple Actions; therefore, it can refer to multiple CSA’s. Crosswalk contains the external system’s ID code, allowing CBS to know which system it is interfacing with.

• The crosswalk drills up from knowing the Action Code to then identify the Subject and, in turn, the Commodity.