Attch_0013_ACWS_DISA_SRF_Form_RiskReduction_2016_04_04.docx

Unclassified

ACWS Attachment 0013 DISA SRF Form Solicitation Number: W52P1J-16-R-0058

ARMY CONTRACT WRITING SYSTEM

(ACWS)

Attachment 0013 ACWS_DISA_SRF_Form_Risk Reduction Version 1.0 04 April 2016 Solicitation Number: W52P1J-16-R-0058

Prepared By:

Product Manager Army Contract Writing System (ACWS)

Enterprise Information Services (EIS) Service Request Form (SRF) Server Hosting

Instructions: Offeror (SI) shall complete Yellow Highlighted area as noted below.

Form Part 1 - Project Overview The Project Overview captures key data about the project in a concise summary format.

· Section 1. System/Application Name – Completed by Government. Is unique and descriptive to avoid confusion with other systems. This is the official name registered in the Department of Defense (DoD) Information Technology (IT) Portfolio Repository (DITPR).

· Section 2. Partner – Completed by Government. The entity with authoritative control over requirements, and usually the entity funding the effort.

· Section 3. Project Title – Completed by Government. A unique name given to the project that is descriptive of the service being requested (e.g., New [Partner system] production web server, [Partner system] Test environment).

· Section 4. EIS Tracking Number – Completed by Government.

· Section 5. Priority. Completed by Government

· Section 6. Designated Hosting Site – Completed by Government. For existing workload indicate the hosting site.

· Section 7. Managing Site – Completed by Government. For existing workload indicate the managing site.

· Section 8. Project Description – Completed by Government. An executive summary of what is achieved through the implementation project and salient project attributes that may influence cost, technical, schedule or Information Assurance (IA) risk. The description must address at least the following topics. Any additional relevant information about the project should also be included.

· Partner’s goal

· Any known IA risks and potential impacts

· Major elements of the solution (e.g., Test and Development [T&D], Continuity of Operations [COOP], Partner equipment, etc.)

· Major phases of the project, as well as timeframes

· Any other unusual requirements or concerns (can be technical, political, etc.)

· Section 9. System/Application Description – Completed by Government. Should provide an overview of the key functional and technical elements of the system and describe what the system will do and look like at the conclusion of implementation. This content can sometimes be extracted from the existing IA accreditation package system description or other system documentation.

· Section 10. Operational Impact – Completed by Government.

· Sections 11, 12, 13, 14, 15 – Completed by Government.

· Sections 16-25. Accreditation Status – Completed by Government and Portions for SI to provide response and return with RFP. Indicates if the workload has an Interim Authority to Test (IATT), Interim Authority to Operate (IATO document their plan to obtain an accreditation decision.

· Section 26. Completed by Government. Application Development Environment. Required after contract award. Development is the process by which something passes by degrees to a different stage (particularly a more advanced or mature stage). The definition includes many phases of the development lifecycle. Development of applications or software will be performed only on Security Technical Implementation guide (STIG) compliant platforms.

· Section 27. SI to provide response and return with RFP. Critical Plans. Required after contract award. In accordance with DoD regulatory guidance, every organization or DoD information system-level IA program is required to have an appointed IA Manager (IAM) who develops and maintains critical plans related to IA architecture, IA requirements, IA objectives and policies; IA personnel; and IA processes and procedures.

· Section 28. SI to provide response and return with RFP. Reviews/Assessments – Required after contract award. Every organization or DoD information system-level IA program is required to regularly and systematically assess the IA posture of information systems, IA services and supporting infrastructures through combinations of self-assessments, independent assessments and audits, formal testing and certification activities, host and network vulnerability or penetration testing, and IA program reviews.

· Section 29. Tool Compatibility – Completed by Government. The Enterprise System Management (ESM) software is the backbone of monitoring and reporting capabilities within the Defense Enterprise Computing Centers (DISAs) and is the key component in feeding the Network Operations (NetOps) environment. Under the sponsorship of the Enterprise-wide IA and Computer Network Defense Solutions Steering Group (ESSG), the Host Based Security System (HBSS) solution will be attached to each host in DoD.

· Section 30. SI to provide response and return with RFP Open Source Software (OSS) – Required after contract award. software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users of that software.

· Sections 31 - 34. Special Compliance Information – Completed by Government. used in the Service Level Agreement (SLA) to identify applications wherein the application data may require special compliance in cases of audit readiness or data calls. An application is not limited to containing only one type of Special Compliance Information; every category that pertains should be indicated. The categories are below:

· Personally Identifiable Information (PII) – refers to data such as people’s names, birth dates, and social security numbers. Training systems would qualify if they record the student’s name and SSN.

· Health Insurance Portability and Accountability Act (HIPAA) – refers to health information regarding patient medical records.

· Financial Systems – contribute, directly or indirectly, to an organization's financial statement. This includes machines that store or process information about assets, payments, financial obligations, or anything else that contributes to financial statement reporting. Examples include ATAAPS, DJMS, and most DFAS applications. If a system merely tracks and reports this type of information, but in no way contributes to a financial statement, it is not a financial system.

· Nuclear Information – indicate if the data being processed contained any information regarding nuclear weapons or warfare.

· Section 35. Data Access – Completed by Government. Used to identify applications wherein access via commercial or NIPRnet may require unrestricted, restricted, or private access.

· Section 36. CAC Enabled – Completed by Government.

· Sections 37-42. Completed by Government and Portions for SI to provide response and return with RFP. Special Audits, Inspections, Assessments, and Tests – used in the SLA to identify workloads wherein the application requires additional audit services above the standard audit support provided. An application is not limited to containing only one type of Special Audit, Inspection, and Test; every category that pertains would be indicated. The categories are below:

· Statement on Standards for Attestation Engagements Number 16 (SSAE 16) – effectively replaces Statement on Auditing Standards Number 70 (SAS 70) that addresses engagements undertaken by a service auditor for reporting on controls at the service organization. The service auditors test and provide an opinion report on the fairness of presentation, suitability of design, and operating effectiveness of the service organization. Two types of SSAE 16 reports are to be issued, a Type 1 and a Type 2. Additionally, SSAE 16 requires that the service organization provide a description of its "system" along with a written assertion by management. Financial Improvement and Audit Readiness (FIAR) Guidance mandates reporting entities are responsible for ensuring that all key processes, systems, internal controls and supporting documentation impacting their financial reporting objectives are audit ready.

· Federal Information System Controls Audit Manual (FISCAM) – provides guidance for performing effective and efficient Information System (IS) control audits, either alone or as part of a performance audit, a financial audit, or an attestation engagement, including communication of any identified IS control weaknesses; and inform financial, performance, and attestation auditors about IS controls and related audit issues. Even though FISCAM is a manual, organizations refer to audits as FISCAM.

· Payment Card Industry (PCI) Data Security Standard (DSS) – a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, Automatic Teller Machine (ATM), and Point of Sale (POS) cards. Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually.

· C&A – set of procedures and assessments leading to a determination of the suitability of the system to operate in the targeted environment. C&A consists of procedures which encompass the entire life cycle of the system; is required before operations begin and at least every three years thereafter or whenever major security-relevant changes occur; and involves an annual IA Controls review.

· Incident Response – federal agencies are required to have in place cyber incident handling mechanisms in accordance with the FISMA (reference a) and Appendix III, Office of Management and Budget (OMB) circular No. A-130, “Management of Federal Information Resources” (reference b).

· Penetration Testing – to enhance the security posture of the DoD network enclaves with the goal to discover weaknesses in systems and/or enclaves before the adversaries discover them. Properly executed vulnerability and penetration tests can identify planning shortfalls, vulnerabilities, deviations from doctrine, and assist administrators in determining the correct countermeasures to mitigate detected weaknesses and enhance their security posture.

Section 43. Points of Contact. Completed by Government.

Sections 44 -47. Target Dates. Completed by Government. Negotiated with the Partner and represent schedule estimates. The Customer Management Executive (CME) team should be sensitive to these dates and proactively communicate with the Partner, as early as possible, whenever the dates are threatened.

Sections 48-51. Risk Assessment. SI to provide response and return with RFP Form Part 2 - Implementation and Cutover Support Requirements The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

Section 1. Implementation Contacts. Completed by Government and Portions for SI to provide response and return with RFP.

Section 2. Migration Requirements. SI to provide response and return with RFP Section 3. Cutover Requirements. SI to provide response and return with RFP Section 4. Performance Metrics. SI to provide response and return with RFP Form Part 3 - Technical Requirements These sections collect details of your requirement that can be directly compiled into a functional specification for your EIS-Standard requirements and will help us assess your requirements better if they are non-standard. Consult the Service Catalog for additional details on our standard services or contact your CME team with questions about filling out this service request.

Note: The best method to add rows to any table in the SRF is as follows:

· Open the File tab, click “Info,” click the “Protect Document” drop-down, and select “Restrict Editing.” In the box that pops up on the right-hand side of the page, click on “Stop Protection.”

· Carefully highlight the entire last row in your table of choice, including the small ‘blank’ space just beyond the outside of the gridline.

· Right-click and select <Insert> and then select <Insert Rows Above>. A new, blank row is now added to your table.

· To populate the new row with a title and those grey input fields, copy a populated row and paste it into your new row. Change the title accordingly.

· Follow the instructions in the first bullet again, but this time click on “Yes, Start Enforcing Protection” in the box that opens on the right-hand side of the page. Do not enter a password and click “OK.”

Note: Check boxes cannot be used in the form unless the Restrict Editing function is turned on.

Form Part 4 - Standard and Optional Rate-Based Services The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

### END OF INSTRUCTIONS ###

Part 1 - Project Overview Project Version Control

Type of Server Requirement:

(select all that apply) |_| New Workload |_| Addition To, or Modification of, Existing DISA Workload |_| Federal Data Center Consolidation Initiative (FDCCI) Project Version:

1.

Date:

SRF Development History

Baseline Change Request (BCR) History

Part 1 - Project Overview Project Identification

9. Project Description – Describe project details, dependencies, and constraints below. Attach any relevant design specifications or documentation to this section.

This ACWS IDIQ contract will procure a COTS-CWS and management solution over a 5-year, up to 10-year, ordering period. Task Order 0001 will initiate the Risk Reduction phase and additional Task Orders will continue through Development & Deployment, to Operations & Support (Reference DoDI 5000.02, Model 3).

The Army Contract Writing System (ACWS) will be the Army's single, next-generation, enterprise-wide contract writing, management, execution, and close-out software system. ACWS will facilitate the standardization of Army Procurement business processes and improve data exchange and business process workflow with selected Army Enterprise Resource Planning (ERP) systems. As a financial feeder system, ACWS will meet the compliance requirements of the Federal Financial Management Improvement Act (FFMIA) of 1996.

The ACWS solution will meet the full scope of Army Contracting requirements and processes, including unique requirements in secure and non-secure locations, unique requirements supporting combat or non-combat contingencies, those within or outside the borders of the Continental United States, those supporting grants and assistance agreements, and those performing weapons systems, construction, installation, and other specialized contracting activities.

When deployed, ACWS will be used by approximately 10,000 end users in Government entities at approximately 300 different locations in support of installation, construction, medical services, expeditionary, transportation, and research and development contracting requirements.

See Attachment 0001 ACWS Statement of Objectives.

10. System/Application Description

Risk Reduction Environment: For the Risk Reduction phase of the contract (12 month period), ACWS will require a hosting environment that allows connections as interfaces to 36 external Defense and Federal System interface partners (e.g., DoD Enterprise Services, Federal Integrated Award Environment, www.FedBizOps.gov, www.SAM.gov)

System Description --- To Be Completed by Government.

11. Operational Impact

Availability [Uptime / (Uptime + Scheduled Downtime + Unscheduled Downtime)]

Restorability (Reliability) Recovery Time Objective (RTO) Recovery Point Objective (RPO) RTO = 24 hours RPO = 12 Hours RTO = 8 hours RPO = 6 hours

Maintainability Mean Time To Repair (MTTR)

|_| Classified |X| Sensitive |X| NIPRNet |_| SIPRNet |_| Partner DAA Accredited Enclave (CDAE)

|_| IATT

|_| IATO

|_| ATO

|X| Not Accredited This system will be assessed for accreditation in accordance with the DoD Risk Management Framework.

SI provide prior accrediting information as applicable.

|_| Configuration Management Plan |_| Risk Management Plan |_| Vulnerability Management Plan |_| Patch Management Plan |_| Incident Response Plan |_| Continuity of Operations Plan |_| Disaster Recovery Plan |_| DoD 8500.2 IA Control Review Location of Review:

|_| Application Security and Development Review Location of Review:

|_| Privacy Impact Assessment Location of Assessment:

30. Tool Compatibility

HBSS |X| Yes |_| No |_| Unknown ESM Software |X| Yes |_| No |_| Unknown

Special Compliance Information (select all that apply)

|X| Restricted (authenticated .com) |X| Private (access from .mil only) |X| Yes |_| No

Special Audits, Inspections, Assessments, and Tests (select all that apply)

Target Dates Initial Operation Environment (IOE) Date – date that Operating Environments (OEs) are turned over to the application administrators for application load Initial Operating Capability (IOC) Date – date that OEs are configured for production users

Risk Assessment Note: IA risk can only be determined by the IA Technical Advisor

|_| High |_| Medium |_| Low |_| High |_| Medium |_| Low |_| High |_| Medium |_| Low

52. Enter Details of Any “High” or ‘Medium” Risks Noted:

SI to complete #48 – 51 with known information. Use the Risk Management Framework to define RISK.

Part 2 - Implementation and Cutover Support Requirements

1. Implementation Contacts

2. Migration Requirements

(e.g., DB Export, Flat File, OVA Image) File Transmission Method (Offline Copy, Online Copy (SFTP), Array-to-Array Replication, Application Replication) Migration Method (Import, Overlay, Mirror, OVA)

3. Cutover Requirements

4. Performance Metrics

Part 3 - Technical Requirements

1. Partner Disposition – Which of these statements best describes the Partner’s view of their technical requirements?

Other (fill in here): SI: Please review the planned activities for the Risk Reduction efforts and make appropriate recommendation for this environment. The activities may occur concurrently.

(“P” or R”)

SI to complete for what is known.

If T&D is a requirement, indicate the Zone where the workload will reside.

|_| Zone A |_| Zone B |_| Zone C |_| Zone D

3. OE Storage Requirements – Specify the storage that is required by each OE (usable storage in GB)

Total Usable Storage Required (in GBs):

4. Web Interfaces – Identify URLs required and their attributes Public – Any service intended to provide unclassified and non-sensitive information accessible from outside the NIPRNet, to include anonymous access.

Restricted – Any service intended to be accessible from the Internet and serves sensitive information to a limited set of users. Access controls are in place to limit the user set who can access the service.

Private – Any service meant to be accessed only from the NIPRNet or SIPRNet, respectively (.mil only).

(see definitions above) Load-balanced to Multiple Web Servers (Yes/No)

5. External System Communication Requirements – List the OEs that require communication with any external system. Specify the ports and protocols used by each. This does not include external access for administration by privileged users.

6. Internal System Communication Requirements – List the OEs that require communication with other OEs within the enclave. Specify the ports and protocols used by each.

7. Software Requirements – List all application software, tools and accessories. Do not include EIS-provided Enterprise Systems Management (ESM) software.

8. Open Source Software Requirements – List all open source software used. For open source, indicate whether or not the software has been DAA-approved. List additional information (i.e. licensing, vendor support, etc.) in the Notes column.

Software Vendor Software Name Version Information

9. User Authentication Requirements

Does user authentication / authorization require access to a remote resource (e.g., LDAP, AD)? |X| Yes |_| No

If Yes, who will manage the authentication / authorization database? CAC Enabled verified by Global Address List

10. Networking & Security

Describe any specific data protection requirements (e.g., data at rest) specified by the data owner.

N/A at this time. SI to complete for what is known.

Describe any interconnection requirements among DoD applications operating at different classification levels (e.g., SIPRNet to NIPRNet or vice versa).

NA at this time. SI to complete for what is known.

Describe any system-to-system interfaces with government agencies, commercial companies, foreign countries, etc.

See attached embedded file (ACWS Interfaces.doc)

Characterize anticipated aggregate bandwidth requirements (data center inbound/outbound). (SI to Complete)

Load Balancing: Describe any local or global application and/or server load balancing requirements. (SI to Complete)

11. Local High Availability Requirements – Does the system require any specific local high availability feature for any specific OEs or functions (e.g., clustering, Oracle RAC)?

|_| Yes |_| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., active, passive, RAC) below:

SI comment if needed.

12.

Remote or Second Site High Availability Requirements – Does the system require remote or second site high availability feature for any specific OEs or functions (e.g., remote failover, clustering, Oracle RAC)?

|_| Yes |_| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., synchronous, asynchronous, RAC) below:

If comment if needed.

Part 4 - Standard and Optional Rate-Based Services

1. Core Services – Every workload hosted in the DISA is assessed Basic Services.

2. Optional Services – Standard solutions must include “Hardware Services” and may include any of the “Optional” service shown below. Review and check any requested optional services:

Application Support – Tier 2 Service Desk support of a dedicated application. Examples include running special jobs on behalf of users, re-running aborted jobs, loading new releases of functional-user software, etc. If application support is selected, it will be applied to all OEs associated with a Partner’s workload except for DISA-provided or Web Administration OEs.

Database Administration – Includes the labor to provide Database Administration support and to ensure databases comply with security guidelines. It only applies to Database servers.

Oracle Grid Control – Provides the EIS standard web based database monitoring and management interface to Partner DBAs. It is included if the Partner is paying for Database Administration, but can be selected as an option by those Partners who elect to perform their own DBA support. It is billed at 10 percent of the Database administration rate.

Database Software Maintenance – Maintenance of Oracle database software. Costs associated with this include the software maintenance and not the license itself. Note: DB Software Maintenance is a required service if EIS provides Oracle licenses.

24 x 7 System Administration – Provides seven days a week, 24 hours a day (24x7), full system administration support. Standard system administration support is part of Basic Services.

24 x 7 Application Support –Provides seven days a week, 24 hours a day (24x7), full application support. Select this option if the standard 8x5 with two hour after-hours response time is insufficient.

24 x 7 Database Administration – Provides seven days a week, 24 hours a day (24x7) full database administration support. Select this option if the standard 8x5 with two-hour after-hours response time is insufficient.

3. Conditional Services – Conditional services may be required depending upon the optional services selected. Review and check any applicable conditional services that apply:

Capacity Planning Reporting – Partners who maintain their own hardware and do not pay the Hardware Services rate may elect to receive capacity planning reports billed at 10 percent of the Hardware Services rate.

4. Service Continuity – If remote site COOP support is required, please select one of the options below:

(RTO = 5 days, RPO = 7 days) – MAC III applications only

(RTO = 5 days, RPO = 8 hours) – MAC III applications only

(RTO = 24 hours, RPO = 8 hours)

(RTO and RPO = 8 hours)

(RTO = 30 minutes, RPO = 1 Sec)

Note any special considerations related to your Service Continuity requirement here and provide more detailed specifications in the Non-Standard Requirements section, if applicable:

ACWS will be a collaborative effort between DISA and the ACWS PdM to successful implement and cutover to the Disaster Recovery environment.

No single points of failure on critical assets: redundant power supplies on servers, switches, and critical network components, dual comm paths but no clustering in the initial phase.

Establish/Select secondary data center locations for disaster recovery services. Data center services will include network, backup/recovery, and storage infrastructure to support both primary and secondary environments.

SRF Server Template Version 2.8 – February 4, 2014 image2.emf

ACWS Interfaces August 2015.xlsx Sheet1

Interface/Partner System Organization Interface/Acronym System Description

Automated Business Services System USAF ABSS The Automated Business Services System (ABSS) is an electronic document processing system. ABSS automates the process of document generation, document coordination, and electronically feeds commitment data to accounting and contracting systems. The system reduces document processing time, applies the Standard Document Number and allows traceability of the on-line documents. ABSS is the primary financial system of record for Air Force commitment documents and is deployed to 193 AF, AFRES and ANG sites. It is used by over 20,000 individuals worldwide and processes over 410,000 electronic commitment and obligation documents per year.

Corps of Engineers Financial Management System USACE CEFMS CEFMS is the Corps of Engineers Financial Management System. It is an online interactive AIS written in Oracle and running on SUN equipment at the Corps’ Western Processing Center in Portland, Or, and the Central Processing Center at Vicksburg, MS. Development of CEFMS began with data and process modelling in the mid 1980’s and deployment has only recently completed. CEFMS is an exemplar of end user controlled software development. The entire development process as effectively been under the sole control of the Resource Management (RM) community, and all programming has been done by contractors under RMs’ direction. CEFMS is one of the first DA systems to employ electronic signatures, using a mechanism developed for the Corps by the National Institute of Science and Technology (NIST). All of the electronic signature process development was approved through the Government Accounting Office. At this point the CEFMS process is so tightly integrated into the financial expenditures processes of the Corps that it would be extremely difficult for the Corps to operate without it.

Centralized Information System for International Logistics DSCA CISIL CISIL is one of four FMS Case Execution system that supports overall coordination to initiate case, implementation efforts required to conduct and execute case management, security assistance, team management, technical, logistical, and financial support, and the contractual efforts under acquisition and contracting. ACWS will need to receive requisition data from CISIL and transmit award data to CISIL.

DPAP Clause Logic Web Service DPAP CLS The Clause Logic Service (CLS) is a web service designed to aid in the procurement process within the Department of Defense and other federal agencies. The primary function of this service is to allow for consistent inclusion of provisions and clauses into procurement documents. The goal of CLS is to improve the integrity of contracts developed by providing a centralized, web based, intelligent business logic clause-generating service for Defense Contract Writing Systems (CWS).

Contractor Manpower Reporting Application ASA(M&RA) CMRA The Contractor Manpower Reporting Application (CMRA) is designed to collect information on funding source, contracting vehicle, organization supported, mission and function performed, and labor hours and costs for contracted efforts providing services to the Department of the Army from contractors and Army activities requiring contracted services from supporting contracting offices. The data reported utilizes an application called CMRA to capture the required information. Contractor Manpower Reporting enables the Army to:

• fully understand the composition of the Army workforce (military, civilian, contractor), and allows for more informed decisions on workforce staffing and funding decisions;

• provide better oversight of the total Army workforce to avoid duplication of effort or shifting of in-house reductions to contract; and

• better account for and explain the total workforce.

Contracting Officer's Representative Tool DPAP CORT The Department of Defense (DoD) Contracting Officer Representative Tracking (CORT) Tool is a web management capability for the appointment of CORs. This Tool allows a perspective COR, COR Supervisor and Contracting Officer to electronically process nomination of CORs for one or multiple contracts. It provides built in workflows for the nomination process to include email alerts/status reminders for monthly status report due-ins and delinquencies. The CORT Tool provides contracting personnel and requiring activities the means to track and manage COR assignment across multiple contracts across DoD.

Contractor Performance Assessment and Reporting System GSA CPARS CPARS is a web-enabled application that collects and manages the library of automated Contractor Performance Assessment Reports (CPARs). A CPAR assesses a contractor's performance and provides a record, both positive and negative, on a given contractor during a specific period of time. CPARS collects contractor performance information and passes it to the PPIRS, where it can be retrieved by all Federal agencies.

Defense Assistance Awards Data System DMDC DAADS The Defense Assistance Awards Data System (DAADS) application is utilized to capture all types of assistance awards made by DoD agencies, which in turn provides:

a) A basis for supporting the Federal Funding Accountability and Transparency Act (FFATA) by reporting to the Federal USASpending.gov System.

(b) DoD inputs to meet statutory requirements for Federal Government-wide reporting of data related to obligations of funds by assistance instrument

(c) A source for fulfilling standard requirements and special reports to the President, the Congress, the General Accounting Office, the National Science Foundation, and the public.

(d) Information to support policy formulation and implementation and to meet management oversight requirements related to the use of awards

Defense Automated Message Exchange System DLA DAMES DAMES is a DLA owned secure messaging system used to exchange requisition (80 card column format) requirement information, formatted messaging and related business data with foreign military customers. (ACC-Warren Only)

Defense Enterprise Accounting & Management System USAF DEAMS The Defense Enterprise Accounting and Management System (DEAMS) was approved under Business Management Modernization Program (BMMP) as a joint United States Transportation Command (USTRANSCOM), Defense Finance and Accounting Service (DFAS), and Air Force (AF) project to replace legacy systems using an enterprise architecture with commercial-off-the-shelf (COTS)-based financial accounting software (general ledger, accounts payable, accounts receivable, financial reporting, billing, etc.). DEAMS will use a Joint Financial Management Improvement Program (JFMIP)/Financial Systems Integration Office (FSIO) certified COTS software package (Oracle) as its core system software and will conform to requirements promulgated by the Office of Management and Budget (OMB), Chief Financial Officers (CFO) Act, Government Performance and Results Act (GPRA), Government Management Reform Act (GMRA), Federal Financial Management Improvement Act (FFMIA), Office of the Secretary of Defense (OSD) Business Enterprise Architecture (BEA) and other related laws, regulations, and policies. Accurate, reliable, and timely financial information is a top priority of the Secretary of the Air Force and Chief of Staff of the Air Force (CSAF). This can only be achieved through a modernization and integrated software solution accompanied by sound accounting processes proven through successful audits.

DLA Logistics Information Service DLA DLIS The DLA Logistics Information Service, or formerly the Defense Logistics Information Service provides logistics and information technology services to the United States Department of Defense, Federal agencies, and international partners.

Defense Medical Logistics Support System DHA DMLSS The Defense Medical Logistics Standard Support (DMLSS) is an information technology system within the Defense Medical Logistics – Enterprise Solution (DML-ES) portfolio. The DML-ES portfolio provides a continuum of medical logistics support for the Defense Health Agency. DMLSS delivers an automated and integrated information system with a comprehensive range of medical materiel, equipment, war reserve materiel and facilities management functions.

Electronic Data Access via GEX DPAP EDA Electronic Data Access (EDA) is a joint repository used by the program management, finance, disbursing, contracting, industry trading partners, other federal agencies, and the logistics community to store and manage common documents. EDA has been undergoing a transformation since 2008 to store and manage Procurement Data Standard (PDS) compliant contract data as well as historic PDF files and key elements of the Electronic Data Interchange transactions. This allows EDA to present contract data in a standard way for all of DoD regardless of which contract writing system generated the contract transaction. Today, contract writing systems using PDS can send and store contract awards, orders and modifications. ACWS is required to send PDS files to EDA.

EDA is a mandatory DoD system as a master repository for unclassified DoD contracts, orders and modifications in accordance with DFARS PGI 204.201. Classified environments are encouraged to mirror the EDA data environment to ensure data integrity can be achieved across the department.

Enterprise Data Warehouse USACE EDW The Enterprise Data Warehouse will supplement and replace multiple legacy AIS databases that currently provide only summary roll up data to USACE executive management. The EDW will provide USACE leadership with an improved executive level reporting capability, producing more comprehensive data allowing for more informed executive decision. Implementation of the EDW will provide a single repository of summary level data accessible throughout the USACE organization. The adoption of a centralized IT solution eliminates multiple Oracle databases that are currently used to house historical information for Corps AIS, and eliminates the need for additional databases to support emergent customer requirements to establish new views of existing data based upon business lines. In short, the EDW fulfills the goals of the CIOs 700 Day Plan/ by offering the USACE community increased functionality at a lower cost through the adoption of Enterprise IT solutions.

Electronic Subcontracting Reporting System GSA ESRS eSRS provides the government with insight as to how its contracting dollars are being distributed among small and disadvantaged businesses. This authoritative source of subcontracting information provides government users the ability to generate reports and creates higher visibility and increased transparency into subcontracting accomplishments across the government.

Federal Awardee Performance and Integrity Information System GSA FAPIIS Section 872 of National Defense Authorization Act of 2009 (Public Law 110-417) required the development and maintenance of an information system that contains specific information on the integrity and performance of covered Federal agency contractors and grantees. FAPIIS was developed to address these requirements. FAPIIS is a distinct application that is accessed through the Past Performance Information Retrieval System (PPIRS) and is available to federal acquisition professionals for their use in award and responsibility determinations. FAPIIS provides users access to integrity and performance information from the FAPIIS reporting module in the Contractor Performance Assessment Reporting System (CPARS), proceedings information from the Central Contractor Registration (CCR) database, and suspension/disbarment information from the Excluded Parties List system (EPLS).

Federal Business Opportunities (FBO) GSA FBO The purpose of FedBizOpps is to collect, maintain, and disseminate information on Federal procurement solicitations to the public. The system also collects voluntary contact information (e-mail address) on individuals and company information on vendors who use FedBizOpps to find and respond to Federal business opportunities for their products and/or services. This information is used to administer and manage Federal buyer access, maintain interested vendor lists, and keep vendors informed of Federal solicitations of business interest.

Federal Procurement Data System - Next Generation GSA FPDS-NG The Government needs to understand where tax dollars are spent. The ability to look at contracts across government agencies, in greater detail, is a key component in establishing trust in our government and credibility in the professionals who use these contracts. Further, it provides opportunity for the government to better assess where its money is being spent, thereby offering opportunities to better determine how to most effectively and efficiently expend those resources. FPDS-NG contains contracting data that allows for this kind of insight. It is also relied upon to create recurring and special reports to the President, Congress, Government Accountability Office, federal executive agencies and the general public.

Federal Funding Accountability and Transparency Act Subaward Reporting System (FSRS) GSA FSRS FSRS is an addition to eSRS built to meet requirements of the Federal Funding Accountability and Transparency Act (FFATA). The intent of FFATA is to empower every American with the ability to hold the government accountable for each spending decision. The expected end result is to reduce wasteful spending in the government. The FFATA legislation requires information on federal awards (federal financial assistance and expenditures) be made available to the public via a single, searchable website, which is www.USASpending.gov. The FFATA Subaward Reporting System (FSRS) will collect data from Federal prime contractors on subcontracts they award and populate USASpending.gov.

Global Exchange DPAP GEX The GEX validations for the PDS enforce FAR- and DFARS-based business rules that have been documented as constraints and data values in the PDS schema. Monitoring tools and diagnostics have been set up to give digital feedback to system administrators as well as functional contracting staff at each contract writing instance in DoD. Using the GEX enables DFAS, DCMA, USD (Comptroller), USD (P&R) and the logistics community to capitalize on the efficiencies of standard transactions by eliminating the need to coordinate and create point to point interfaces. The GEX is a critical capability for the current and future contract writing and administration environment to achieve and maintain efficiencies. ACWS is required to send award and modification files in the standard PDS format for consumption by downstream systems. ACWS is also required to be capable of sending and receiving files I the Purchase Request Data Standard (PRDS).

General Fund Enterprise Business System ASA(FM&C) GFEBS The GFEBS Solution Architecture supports the realization of an integrated SAP-based General Fund core Enterprise Resource Planning (ERP) solution for the Department of the Army. GFEBS enables the Army to improve performance, standardize processes and ensure it meets future needs in peacetime and war.