ATCH_13_-_BIO_TO_PWS_A4.docx

Performance Work Statement (PWS) for Business Integration Office (BIO) Assistance Task Order U.S. Department of the Interior (DOI) October 21, 2013 Contents

1.0 Background and Objective

1.0.1 This PWS specifies critical support services required by the U.S. Department of the Interior (DOI), Business Integration Office (BIO), to accomplish its mission. These services shall also be provided to other parts of DOI for BIO related activities. The mission of the BIO is to perform Financial and Business Management System (FBMS) operations and maintenance (O&M) including Tier 2 Help Desk support and managing software upgrades; manage overall system security; perform Business Intelligence reporting development and support; manage and deliver training in support of process standardization; optimize the FBMS solution, including mobile and light applications (where effective) and in support of legislative and regulatory compliance; lead application leverage efforts, based on the direction of FBMS governance; and take a leadership position in the U.S. Federal workspace for FBMS software products such as SAP ECC, SAP BusinessObjects, and PRISM.

1.0.2 FBMS is the cornerstone of a fully integrated business management system, supporting DOI as a world-class organization acknowledged for management excellence and effective mission delivery. It is critical to the DOI’s financial management modernization strategy and to meeting future business needs. FBMS is a functionality driven SAP and Compusearch solution designed to incorporate the majority of DOI’s financial management functions into one system. FBMS uses many modules of SAP, see Attachment #1 for a complete list. DOI strived for the least amount of customization and promotes business process standardization across bureaus. Still, all system implementations require some amount of configuration and customization. The FBMS custom development objects are listed in Attachment #2. This integrated system will ultimately eliminate over 80 DOI and bureau-specific systems and enable the alignment of a business management system with the DOI’s strategy of modernization, integration, accountability, and customer value. The full implementation of FBMS allows the DOI to realize the benefits of common processes, a common technology platform, integrated real time data, and improved operational decision making. FBMS will achieve the initial goal of having all of DOI on one system with Deployment 8 (D8) go-live in November, 2013. For an introduction to FBMS, please see http://www.doi.gov/fbms.

The figure below illustrates the FBMS Deployments to date.

Figure 1.0 FBMS Deployments

1.0.3 The Business Integration Office (BIO) is the successor to the FBMS Program Management Office (PMO). The PMO was assigned with developing and deploying FBMS to all of DOI. D8 completes this original assignment. The scope of the BIO is larger than simply supporting FBMS. The primary difference between FBMS PMO scope and BIO scope is that the BIO is not constrained to FBMS support alone, but is tasked with supporting the full functional scope under the Deputy Assistant Secretary for Budget, Finance, Performance and Acquisition (DAS-BFPA). This may include managing or providing assistance to other systems closely aligned with FBMS such as Concur Government Edition (CGE) travel or supporting Roadmap efforts resulting in projects or new systems.

1.0.4 The BIO directs the work of a variety of Government and contracted resources in order to achieve program objectives. The BIO consists of several workstream teams all of which contain an integrated mixture of Federal and contractor resources. These teams have worked closely with the System Integrator (SI) to identify scope, develop custom objects, and deploy FBMS to all of the bureaus in the DOI. The current System Integrator is IBM. The system integration contract is designed to end in February, 2014, shortly after the final quality gate of D8. Initially the SI team was very large and was responsible for the vast majority of all the development work needed to conduct the deployments. Over the last 3 years, the SI staffing level has decreased as primary responsibility for segments of the deployments has shifted from the SI to the BIO teams, thus making the BIO less reliant upon the SI.

1.0.5 The FBMS deployments have followed a cyclical development process with each deployment increasing functional scope while transitioning additional bureaus into FBMS. Operations and Maintenance (O&M) support to the deployed bureaus is being provided simultaneously with ongoing development. O&M support will continue through 2030. To date, the FBMS PMO has completed seven deployments that have added nine bureaus into FBMS production. The final deployment is on schedule for taking the last bureau to production in November, 2013. The BIO will continue to ensure FBMS is up to date and meeting DOI needs. The BIO will also continue to optimize this initial investment in FBMS and leverage this investment as appropriate with expanded functionality.

1.0.6 Objective: In summary, the purpose of this acquisition is to acquire services to support the BIO Federal staff. The contractor shall perform duties related to FBMS Production support and development, technical support of the FBMS environments, project management, and managing or providing assistance to other systems closely aligned with FBMS.

1.1 BIO work environment

The scope of BIO work consists of three primary types of work: FBMS Production Support and Development; Technical Support; and Project Management Support. The scope of this task order is to support all 3 of these types of work. The bureaus and offices, as users of FBMS and other BIO services, have similar support needs. The intent of this task order is to provide a vehicle for bureaus and offices to issue task orders for similar support. The Government recognizes that the most efficient solution to this type of support may include resources being shared across task orders. The following information is provided to explain the organization and work environment of the BIO within which the work under this task order needs to be accomplished.

1.1.1 Current and Future Organization Structure

The current BIO is comprised of approximately 70 Federal employees, 87 BIO support contractors that are within the scope of this procurement, and 6 BIO support contractors that are not within the scope of this procurement. The BIO is also currently supported by approximately 50 System Integrator (IBM) contractors, all of whom will roll off of the project between October 2013 and February 2014.

The FBMS Project Office is located primarily in two cities: Herndon, VA and Lakewood, CO. Current DOI project staff is split approximately 50/50 between Herndon and Lakewood. In Herndon, the PMO is located at 13461 Sunrise Valley Drive. The Lakewood space is at the Denver Federal Center, Building 810.

All workstreams within the BIO include Federal employees that work alongside contractor resources. Each team is led by a Federal employee. The Federal resources on each team provide the subject matter expertise on DOI policies and procedures. These same government resources also provide functional or technical support for FBMS, including incident management, user assistance, program documentation, system administration, report development, application development, security or any of the other responsibilities of the BIO. These same Federal resources could be assigned to any other BIO project.

The BIO is continually evolving, while maintaining balance between supporting processes that are currently working and migrating to new processes that will improve the efficiency of the BIO. For example, the incident management processes are difficult for the BIO to change because of the many parties involved. Incident management and the tool for incident management are partially dictated to the BIO through our partnership with the DOI central IT service desk. Incident management also impacts all of the bureaus. On the other hand, the BIO does not have an established approach to agile projects. The BIO may also be open to changes within the team structures, especially how the contractor integrates with the Government teams, as we move from work that has been dominated by large bureau deployments to work that will be dominated by production support and smaller functionality deployments.

An organization chart, based on current plans/scope, is included as Attachment #3. This chart portrays the BIO organizational structure, effective October 1, 2013, in addition to displaying certain added contractor positions over and above the current BIO support contract for those areas where the Government foresees a knowledge gap caused by the S.I. contract ending.

NOTE: The number of current contractor positions shown on this chart is provided to prospective offerors in order to illustrate the BIO organizational structure and the nature of the Federal/contractor mix within each of the respective teams. This should not preclude offerors from proposing a different number or mix of contractor resources in order to accomplish the work outlined in this PWS.

The BIO is made up of five divisions, along with a Chief of Staff office to handle BIO business administration. Two of the five divisions are focused on service delivery (Production Management and Project Management) and have a role in outlining workload priorities for the other three divisions (Business Process; Applications Management; and Technical Infrastructure, Security, and Quality Management).

The Business Process Division is by far the largest division in the BIO. It is comprised of mostly individuals (both Federal and contract) with expert functional knowledge in one or more of the business functions and related software products within FBMS. It is divided into 3 functional teams: Core Finance, Property, and Acquisitions/Financial Assistance, and also a separate Training team. Their work environment and associated work requirements are described below within the Production Support and Development sections (1.1.2 and 2.1).

The Applications Management Division is comprised of mostly IT professionals providing service in 3 distinct branches: Applications Development, System Administration, and Business Intelligence(BI)/Portal. The Applications Management Division work is described primarily under the Technical Support sections (1.1.3 and 2.2) below. The Applications Development branch is comprised of 2 teams: Conversion Team (most of whom will be rolled off the project after completion of Deployment 8 in November 2013) and the Application Development team which is comprised primarily of ABAP programmers. The System Administration Branch has 3 teams: the Enterprise Application Integration (EAI) team which supports all of the interfaces within the FBMS framework; the Stress and Volume team which maintains the automated test scripts and conducts system testing; and the System Administration team which keeps all of the systems within the FBMS landscapes up and running. The BI/Portal Branch is comprised of reports analysts and BI and Portal developers.

The Technical Infrastructure, Security, and Quality Management Division is comprised of a variety of different functions. There are 2 branches in this division: Technical Security and Quality. The Technical Security branch provides application security for FBMS and also provides onsite IT support for the BIO facilities and staff. The Quality Branch has a variety of quality assurance related staff including those focused on testing management and coordination, change management, project tools administration, and information assurance. The work for this division is described within the Technical Support sections (1.1.3 and 2.2) below.

The Production Management Division is primarily focused on FBMS Production issues and processing; the Project Management Division is primarily focused on managing deployment activities (Development) for future releases and for other non-FBMS projects. The staff of the other 3 divisions work on both FBMS Production and Deployment activities, so the BIO takes a matrixed approach to providing leadership and direction to these divisions via using the Production Management and Project Management staff. The work environment and associated work requirements for the Production Management team is described below within the Production Support and Development sections (1.1.2 and 2.1). The work environment and associated work requirements for the Project Management team is described in the Project Management sections (1.1.4 and 2.3) below.

1.1.2 Production Support and Development environment

This section provides information describing the current production support and development environment and also the projected future environment where feasible. This work is primarily accomplished by resources from the Business Process Division, with support from Applications Management and Technical Divisions, and based on direction from the Production Management and Project Management teams.

Although Production Support and Development are distinctly separate processes driven by different factors, much of the work performed is similar and is performed by the same people. As stated previously, almost all of the analysis and testing work required to perform these functions are performed by teams within the Business Process Division. Each of the teams within this division, is comprised of a combination of Federal and contractor employees. With few exceptions, every person works on both Production Support and new development. Some staff may work primarily on production issues and not as much on development, while others are the reverse. This varies from person to person within each team. All of the Technical work required to support Production Support and Development is performed by the Applications Management and Technical divisions. The Technical work environment is explained in greater detail in Sect. 1.1.3.

1.1.1.1 Production Support Environment

This section will describe the work environment for Production Support.

1.1.2.1.1 Remedy Incidents. The primary driver of work in Production Support is responding to incidents. Incidents are logged by either bureau users or other BIO team members in an incident management system managed by the Interior Business Center (IBC) called Remedy. IBC serves as the Level 1 Help Desk for FBMS. They historically have resolved about 10-20% of tickets on first contact, with many of these related to master data maintenance (MDM) as IBC manages the vendor and customer table updates for all of FBMS. They also can perform password resets. The vast majority of incidents (80-90%) are then assigned to Level 2 Help Desk personnel. FBMS policy is that unless the incident is for a known issue that only the BIO can resolve, these incidents are first assigned to Level 2 Help Desk staff located in the respective bureaus. If the bureau staffs are unable to resolve the issue, either through lack of knowledge, lack of needed system access, or it is obvious that a system fix or enhancement is needed, the incident is then assigned to the BIO. Based on historical data, approximately 60-65% of the incidents end up at the BIO for resolution.

The following tables provide data regarding current Remedy incident activity along with projections for the remainder of FY13 and for FY14 based on trend data and projected number of users. Incident activity is primarily driven by user count and also by deployment of new bureaus or of major new software features. User count data will be presented in the section that follows this one. The incident data presented includes data for FY09 through FY13 as of March 20, 2013. The remainder of FY13 is a projection, along with projections for FY14. Incidents submitted for MDM for resolving at the IBC have been excluded. Incident count data is present in two broad groups: Application Management, which are more functionally related issues; and Operations, which are more technically related issues. The further breakdown provided by detailed topic areas in tables later in this section, can be directly related to teams provided in the organization chart as to who primarily works on these incidents.

Table 1.1.2.1.1 FY13 & FY14 Remedy FBMS incident summary

FBMS Incident Analysis - Summary FY13 & FY14 estimates

Application Management

Operations

Table 1.1.2.1.2 Actual and Projected Incident counts for Applications Management - Summary

Application Management (Actual and Projected)

Table 1.1.2.1.3 Actual and Projected Incident counts for Applications Management - Detail

Aviation

Financial Assistance

Table 1.1.2.1.4 Actual and Projected Incident counts for Applications Management – Detail for Core Finance

IBC Payroll Operations Div

Waivers

Table 1.1.2.1.5 Actual and Projected Incident counts for Applications Management – Detail for Property

Energy

Inventory Mgmt

Table 1.1.2.1.6 Actual and Projected Incident counts for Operations - Summary

The table below shows open incidents within aging category. Note that as of the time of this report, only 432 (52%) of these incidents were assigned to PMO staff – the rest were assigned to either the bureaus or the IBC.

Table 1.1.2.1.7 Aged Open Incidents by Functional Category as of August 27, 2013

1.1.2.1.2 FBMS User Count

The table below shows the individual bureaus, their user count as of 3/25/13, the year the bureau initially started on FBMS, and projections for Fiscal Year 2014. These user count projections were used in the Remedy incident projections above. The National Park Service and Indian Affairs user base is expected to continue to grow during FY13 and stabilize in late FY13. Similarly, the Bureau of Reclamation user base will grow throughout FY14. The user base is expected to stabilize in FY14 and be similar in future years.

Table 1.1.2.1.2 FBMS Users by FY of Deployment

1.1.2.1.3 PSL-CRs

Another leading indicator of the work performed by the Production Support team is Production Support Landscape-Change Requests (PSL-CRs). If a resolution to a Remedy incident requires any significant configuration changes or any modifications to development objects, a PSL-CR is required. All PSL-CRs go thru a governance process and must be approved by BIO management. PSL-CRs must be thoroughly documented, including a diagnosis of the problem, recommended solution, test plan, test results, and verification that all associated system documentation has been updated based on the changes made in the PSL-CR.

Provided below are PSL-CR statistics for FY13 thru Aug 31, 2013. For much more detailed information on PSL-CRs, including data for FY11 and FY12, please see Attachment #4.

Table 1.1.2.1.3.1 PSL-CRs – FY13 by Product Type (Functional Area)

Product Type

Table 1.1.2.1.3.2 PSL-CRs – FY13 by Affected Application

Affected Application

1.1.2.1.4 Batch Processing Support

Within the Production Management Division, there is a team that is focused on production batch processing only. The Batch Processing Support Team supports production processing for over 6,000 jobs. Support includes: documenting technical and scheduling specifications for all jobs, working with IBC on testing and implementing new jobs, working with IBC on testing jobs for updates and or changes, coordinating job failure resolution with functional and technical staff and providing after-hours on-call support for job failures or processing issues.

Note: IBC provides Control-M technical support to the FBMS PMO including job creation and job monitoring.

1.1.1.2 Development Environment

The approach to managing the work of the BIO can be summarized by saying that the BIO will continue to operate FBMS and provide user support for FBMS, to continually improve FBMS, and to serve DAS-BFPA needs. The BIO anticipates yearly software upgrades to FBMS to maintain currency and relevancy. Planned work will also include administrative directives provided by outside third parties (example: OMB, Treasury or GSA) or the FBMS System Sponsor or Owners. Administrative directives may also be formed through DOI Road mapping efforts. The BIO will directly or indirectly support the Financial Management, Budget and Planning, Facilities Maintenance and Management, and Revenue road maps. The BIO anticipates one or more releases to FBMS to incorporate changes to optimize the business processes supported by FBMS and the FBMS system itself. These optimization improvements are managed and prioritized in conjunction with the FBMS user group (known as the FBMS Software Advocacy Leadership Team (FSALT)), System Sponsor, and System Owners. All changes to FBMS are managed through our governance process that includes the above FSALT input as well as the FBMS Executive Steering Committee. The amount of optimization changes will be scheduled to comply with available resources. This governance process is further explained in Section 1.1.5.1.

1.1.2.2.1 BIO Life Cycle Management Methodology

For system development and deployment purposes, the BIO has used a structured approach based on the Ascendant SAP phased methodology. A project plan is developed based on the following phases shown in the diagram below, with a brief description of each phase.

Figure 1.1.2.2.1 Ascendant SAP phases

· Project Preparation – making the plan of what to build, how long to do it

· Business Blueprint – refining/understanding requirements; develop business processes to build upon

· Realization – build it and test it (and test it, and test it…..)

· Final Preparation – user acceptance testing, cutover activities, training

· Go-Live and Support – cutover is complete, begin entering transactions

· Sustain – normal operations

Each of the phases ends with a quality gate, when an exhaustive check list is reviewed and verified by all the BIO teams and presented to DOI, BIO, and bureau management for approval. This quality gate process confirms that the deployment is ready to move into the next phase. This means that either all of the checklist items are completed, or there is a plan in place to complete those incomplete items in a timely manner.

The BIO intends to continue to use this model going forward in regards to its planned annual major releases. The number of quality gates will be reduced from when this was used to deploy FBMS at the bureaus. The timeline for Deployment 9 has already been established with the dates below. Although this process will be used as a basic model for major annual deployments going forward, the timing of those deployments may be changed based on the results of a project currently being undertaken by the BIO and FSALT to look at possible major revisions to the overall FBMS release strategy now that all bureaus have been deployed and the requirement for all major deployments to occur at fiscal year beginning may no longer be true.

D9 Phases and Quality Gates:

· DBR - Deployment Baseline Review: July 26, 2013 – DBR signifies the end of the Project Prep phase where scope has been preliminarily agreed upon by all relevant parties. This starts the Blueprint phase.

· PDR - Preliminary Design Review: Dec 18, 2013 – PDR signifies the end of the Blueprinting phase where scope has been verified at a detailed level through completion of Blueprint workshops. Another key output of Blueprinting is revised Business Process Descriptions (BPDs) which describe all of the FBMS business processes at a high level using flowchart diagrams. This gate starts the Realization phase where all development work occurs.

· TRR-I – Test Readiness Review-Integration Testing: May 28, 2014 – TRR-I is not the end of the Realization phase, but it does signify that all development has been completed, and the teams are now ready to perform integrated system testing, followed by user acceptance testing. During the time since PDR, the teams have been modifying or developing functional design specifications (FDS), technical design specifications (TDS), doing programming and system configuration changes, and unit testing.

· PRR: Production Readiness Review: Oct 06, 2014 – PRR signifies the end of the Realization and Final Preparation phases. Testing has been completed, all defects discovered have been resolved, and training materials and schedules have been developed and completed. At this point, the system is brought down and all system upgrades and changes occur. Training classes are given during this timeframe.

· Go-Live: Oct 23, 2014 – Go-Live is the projected date that all system upgrades have been made and verified, and the system is now ready for users to login and begin using the newly upgraded system, in this case Deployment 9.

1.1.2.2.2 System Optimization

In addition to an annual major software release, the BIO plans to incorporate one or more releases per year of optimization items. Optimization items are system improvements identified by the bureaus or BIO through the FSALT. The FSALT is the FBMS Software Advocacy Leadership Team and is comprised of representatives from all DOI bureaus, as well as the BIO and the DOI Policy offices that fall under the FBMS umbrella. In FY13, the FSALT underwent a rigorous process of identifying over 700 optimization items across all of the FBMS subsystems. Functional teams were then formed to review and prioritize each of these items across the DOI. Based on the FSALT identified priorities, a recommended list of optimization items was agreed to by both the BIO and FSALT to be incorporated into FY14 releases. The BIO Business Process teams fully participated throughout this process. This was the first time this process was used to identify optimization items. There will be lessons learned incorporated into this process for the next and future deployments, and the timing of this process in the future is reliant upon the completion of the revised release strategy which was discussed earlier.

Attachment #5 is a presentation used at the D9 DBR on July 26, 2013 and contains additional information in regards to much of the topics discussed above in this section 1.1.2.2, including D9 scope, project phases and quality gates, overall deployment schedule, and potential risks associated with the deployment.

1.1.2.2.3 Training

The Business Process-Training team works with the Subject Matter Experts (SMEs) within the various Business Process teams to develop and update training materials and Work Step instructions (WSI); develop Computer-Based Training (CBT) classes; and deliver Instructor-Led training to support both deployments and a year-round training program.

The table below shows the current number of WSI’s by functional area.

Table 1.1.2.2.3.1 WSIs by Functional Area

This table shows the planned number of Instructor Led classes for the D8 deployment, post-D8 deployment, and brown bag sessions. Brown bag sessions are short 1 – 2 hour classes given on selected topics throughout the year.

Table 1.1.2.2.3.2 Planned ILTs and Brown Bags for FY14 Instructor Led Training classes

Notes:

* Based on Brown Bag numbers from 2013 ** Courses in red are those BIO will be taking over from IBM Post D8

The table that follows shows a list of current CBTs, all of which at this time are maintained by the SI; the maintenance of these CBTs will transfer to the BIO after Deployment 8.

Table 1.1.2.2.3.3 Current CBTs Computer Based Training (CBT)

FBMS Acquisitions Approver

FBMS Acquisitions Receiver

FBMS Acquisitions Requisitioner Part 1

FBMS Acquisitions Requisitioner Part 2

FBMS Analysis for OLAP

FBMS AP Miscellaneous Obligations

FBMS Basic Navigation

FBMS Basic Charge Card

FBMS Advanced Charge Card

Custodial Property Officer Notification

FBMS General Ledger Field Office Accountant

FBMS Labor Adjustments

1.1.2.3 System Documentation

FBMS is a very well documented system. This documentation not only helps the BIO team, but all of its bureau customers and system auditors as well. The processes surrounding this documentation are well-established and strictly followed. Documentation updates are required for both Production Support and Development activities. Following is the key system documentation work products that are maintained by the BIO:

· Business Process Definition (BPD): Used to document each of the identified business processes within the FBMS scope. These are high level documents that use workflows and are an output of the Blueprint phase of system development. These documents are developed and maintained by the Business Process teams.

· Functional Design Specification (FDS): Documentation that describes the requested behavior of a specific development object. The FDS describes what is needed by the system user, as well as requested properties of inputs and outputs, and related error checks and handling. These documents are developed and maintained by the Business Process teams and used as input for the TDS.

· Technical Design Specification (TDS): Documentation that details the essential technical requirements for developing the custom object, including the procedures by which it can be determined that the requirements have been met. The TDS helps avoid duplication and inconsistencies, allows for accurate estimates of necessary work and resources, and acts as a reference document for engineering changes. These documents are developed and maintained by the Applications Development team.

· Unit Testing Plan (UTP) is the plan on how a development object will be tested by the programmer after development is completed and before it is turned over to the Business Process team for Integration Testing. These plans are developed by the Applications Development team.

· Unit Testing Plan Execution document (UTPx) is where the results of Unit Testing is recorded and signed off on. These documents are completed by the Applications Development team.

· Work Step Instructions (WSI): A Training document that provides a step-by-step procedure for executing a specific transaction in FBMS. These documents are very detailed and contain a great many screen shots of exactly what the user should see at each step. These documents are used for both online help and to develop training manuals. They are developed and maintained by the Business Process and Training teams.

The following chart presents an estimate of the total number of updates in any given fiscal year required to be made to our core system documents. These updates would be required for any PSL-CR correction made against a development object or for any modification made to the object as a result of an optimization item or for the annual deployment. If a new development object is approved as part of an optimization release or annual deployment, then these counts will increase.

Table 1.1.2.3 Estimated Updates per year to system documentation work products.

1.1.3 Technical environment

This section provides information describing the current BIO Technical environment and also the projected future environment where feasible. This work is primarily accomplished by resources from the Applications Management and Technical Infrastructure, Security, and Quality Management Divisions, and based upon direction from the Production Management and Project Management teams. Technical support is provided to both those working on Production Support and those working on Development work.

1.1.3.1 FBMS System Architecture

In Attachment #6 is an architectural diagram which depicts all of the FBMS interfaces both internal and external. There are internal interfaces within FBMS modules (e.g., PRISM to SAP), external interfaces with DOI bureau systems (e.g., FBMS to USGS IBIS); external interfaces with other Federal entities (e.g., Treasury’s Internet Payment Platform (IPP) which DOI uses for electronic invoicing); and external interfaces with non-Federal systems (e.g., JPMorgan Chase’s charge card billing system). The BIO Technical teams manage all of these interfaces on a daily basis.

1.1.3.2 Current Hosting Environment

FBMS is currently hosted by the IBC. The BIO is moving this hosting arrangement to a cloud hosting environment. This project to move to the cloud hosting environment (also known as TechRefresh 3) is described in more detail in Section 1.1.6.3 of this PWS. This section (1.1.3.2) describes the current hosting environment to provide an understanding of the complexity of the technical environment.

A visual depiction of the relationship of FBMS software products is shown in Attachment #7. The green box labeled “Budget Formulation” is a potential future module for FBMS. Budget Formulation was in the original scope of FBMS but has never been deployed and there are no current plans to do so in the near future.

Attachment #8 contains a chart which depicts primary FBMS software products with their current and planned versions over the next 3 years.

The FBMS infrastructure follows the standard N+1 SAP Landscape methodology utilizing the SAP 2-tier architecture in the Development landscapes and SAP 3-tier architecture in all other landscapes. FBMS is supported by the standard 5-box landscape for operations support and deployment (production, two development, and two test environments). In addition FBMS has training, production copy (PRODCOPY), and disaster recovery (DR) environments. FBMS is currently running in virtualized, clustered, and highly available configuration on Solaris with Sun Clustering.

The diagram below provides a picture of the FBMS production (PSL) and development (DSL) landscapes, and where the actual current hardware is located.

Diagram 1.1.3.2 FBMS Technical Landscapes

DEV

Environment

PROD

Environment

TRN

Environment

PSL

Fixes

Deployment Builds

Early build to meet training

Availability requirements

PSL

Fixes

U

SGS

RESTON

DDC

Denver

ProdCopy

Environment aka Sandbox

PSL

Landscape

DSL Landscape

DEV

Environment

QAS

Environment

Disaster

Recovery

Environment

QAS

Environment

1.1.3.3 Current and Projected Processing Statistics

The figures to follow are the projected system capacity and memory requirements of FBMS over the next few years. These estimates were produced using the most current methods and models brought to bear by SAP, Oracle, the DOI’s Interior Business Center (IBC), and the FBMS PMO (System Architect), and were validated by objective third-party review in January 2012.

Processing capability is represented in SAPS. The SAP Application Performance Standard (SAPS) is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark, where 100 SAPS is defined as 2,000 fully business processed order line items per hour. In technical terms, this throughput is achieved by processing 6,000 dialog steps (screen changes), 2,000 postings per hour in the SD Benchmark, or 2,400 SAP transactions.

Table 1.1.3.3.1 Processing Capability – SAPS required by landscape

Table 1.1.3.3.2 Processing Capability – SAPS required by software application in Production Environment

Table 1.1.3.3.3 SAPs estimates per production instance by tier for FY2014-2015

Table 1.1.3.3.4 Usable Storage by Landscape per year (cumulative)

Table 1.1.3.3.5 Projected Database Requirements through FY2019 by Environment

The following table represents the current FBMS server count and shows the number of servers the BIO staff needs to monitor to keep all the applications up and running.

Table 1.1.3.3.6 Current number of FBMS servers

1.1.3.4 SAP Transports

The following data charts show the number of SAP transports performed in the Production environment. These are traditionally reduced significantly as we approach FY end since only emergency PSL-CRs are approved in the last quarter of the FY.

Table 1.1.3.4.1 SAP Transports in FBMS Production: Jan-June, 2013 Production Support Transport data

The following charts show historical data on the number of SAP transports performed in the development landscape in order to support the D4 thru D7 deployments.

Table 1.1.3.4.2 SAP Transports to support FBMS Deployments 4 - 7

Deployment Transport Data

1.1.3.5 FBMS Backups

Attachment #9 is the regular backup schedule for FBMS. This includes the FBMS Backup schedule for all the instances.

1.1.3.6 FBMS Development Objects

One of the key drivers of work in Applications Development is the number of development objects that need to be supported. FBMS currently has 438 RICEFW objects (Reports, Interfaces, Conversions, Enhancements, Forms, and Workflows). These are provided in Attachment #2. Offerors may filter on the “Functional Area” column in order to get an idea of how many are in each functional area (e.g., ACQ, AP, etc.).

1.1.3.7 Stress and Volume Testing

FBMS Mercury LoadRunner is used to perform stress and volume testing and automated data creation for some business processes. The BIO does 4 weeks of stress and volume testing each year for the new functionality and software versions. The Stress and Volume team also does stress and volume testing on-demand for any additional performance issues throughout the year. Below are the test scripts/processes that are currently run for the stress and volume testing. In addition, the BIO is in the process of automating the functional test scripts to incorporate automated regression testing for FBMS that is required with each deployment. There are currently just over 400 test scripts in the test script inventory.

Table 1.1.3.7 Stress and Volume Test Scripts executed

1.1.4 Project Management environment

This section provides information describing the current BIO Project Management environment and also the projected future environment where feasible. The BIO Project Management Division (PMD) is responsible for the management and oversight of the BIO’s project portfolio. The nature of the project portfolio changes with changing priorities and initiatives as directed by the System Owner, System Sponsors and external regulatory agencies. In general, projects can be classified into two major categories: optimize projects which further the usefulness of existing deployed functionality and leverage projects which are deployment of entirely new functions or system modules. The project management strategy utilized to support these projects may differ from project to project: a formal System Development Lifecycle methodology for large projects and releases (as described previously in Section 1.1.2.2.1) vs. an agile methodology for more limited projects or minor releases.

The Project Management Division provides leadership and overall direction to FBMS Project activities across all of the BIO Operating divisions. This work is accomplished by resources within the PMD utilizing a matrixed resource allocation model. The PMD has the ability to task resources throughout the BIO in support of ongoing projects. The primary functions performed by the PMD include Project Plan development, oversight, management, reporting and related project management activities for all BIO projects. In the past, large FBMS deployment project plan development and monitoring was handled by the SI ; however, these tasks will be assumed by the BIO PMD moving forward.

In addition to managing the project portfolio, the PMD will manage the resource allocations vs. workload to ensure adequate coverage for all BIO activities. The PMD will liaison with DOI Bureaus through the FSALT on prioritizing optimization items and the related content and scheduling of software releases. The PMD will support various activities to analyze potential workload and future projects for their feasibility and inclusion as future projects. This includes support for DOI Roadmap efforts and other requests by System Owners that may result in future BIO workload.

1.1.5 Core BIO Principles

This section provides some additional information on core BIO principles that apply across the entire BIO organization: FBMS Governance Structure and Program Support Tools.

1.1.5.1 FBMS Governance Structure

There are several entities involved in the governance of FBMS. The FBMS Executive Steering Committee is one of these entities.