Attch_0010_ACWS_Interface_Development_Strategy_2015_12_17.pdf

FOUO

Acquisition Sensitive

FOUO

Acquisition Sensitive

ACWS Interface Development Strategy Version 1.0 17 December 2015

ARMY CONTRACT WRITING SYSTEM

(ACWS)

Interface Development Strategy Version 1.0 17 December 2015

Prepared By:

Product Manager Army Contract Writing System (ACWS)

FOUO

Acquisition Sensitive

1 ACWS Interface Development Strategy Version 1.0 17 December 2015

This page intentionally left blank

FOUO

Acquisition Sensitive

2 ACWS Interface Development Strategy Version 1.0 17 December 2015

Revision History

Version Date Summary of Changes

DRAFT May 2015 Initial draft; requires program-level & functional review to validate assumptions.

REVISED

DRAFT July 1, 2015

Updated system interface partner list to include additional systems added to requirements;

Updated system details based off of additional meetings held with interface partners in May/June 2015.

2nd Revised Draft July 9, 2015

Grammatical fixed; changes Integrated Acquisition Environment to Integrate Award Environment

July 14, 2015 Updated GEX information to include requirement for contract closeout notifications

3rd Draft July 20, 2015 Submission to ACC-RI

4th Draft October 5, 2015

Provided additional details in response to feedback received from Draft RFP publication (partner agreements, appendix with additional interface details, details about Handshakes and BEA P2P content)

Final Draft October 15, 2015 Submission to ACC-RI for Final RFP

FOUO

Acquisition Sensitive

3 ACWS Interface Development Strategy Version 1.0 17 December 2015

Table of Contents

1.0 Overview

1.1 Phased Approach

1.1.1 Phase 1

1.1.2 Phase 2

1.1.3 Phase 3

1.1.4 Additional Development Phases (if necessary)

1.1.5 Operations & Sustainment

1.2 Interface Partner Agreements

2.0 Integrated Award Environment & Department of Defense Enterprise Services Systems 12

2.1 List of IAE & DoD Enterprise Service Systems

2.1.1 IAE and DoD Enterprise Service Systems Considerations

2.1.2 IAE and DoD Enterprise Services System Descriptions

3.0 Core Financial Systems

3.1 Considerations for Development of Financial Systems Interfaces

3.2 Financial Systems Descriptions

4.0 Mission Specific Systems

4.1 Corps of Engineers System Descriptions

4.2 Foreign Military Sales (FMS) Systems Descriptions

4.3 Grants and Assistance Agreements Systems Descriptions

4.4 Medical Procurement Support Systems Descriptions

5.0 Army/DoD Unique Master Data Systems Descriptions

Appendix A: Procure-to-Pay Handshakes

Appendix B: BEA 10.0 P2P Level 1 Process Step Descriptions

Appendix C: Acronym List

Appendix D: Additional Interface Details

List of Figures Figure 1: Conceptual To-Be Systems Landscape

FOUO

Acquisition Sensitive

4 ACWS Interface Development Strategy Version 1.0 17 December 2015

Figure 2: ACWS IOC and FD Roadmap

Figure 3: Interface Development and Agreements Conceptual View

Figure 4: Procure-to-Pay Handshakes

Figure 5: BEA 10.0 Procure-to-Pay Process

Figure 6: Conceptual To-Be Systems Landscape (Functional Perspective)

FOUO

Acquisition Sensitive

5 ACWS Interface Development Strategy Version 1.0 17 December 2015

1.0 Overview

The successful design and development of electronic interfaces is often the most complex, costly, and time-consuming aspect of solution implementation. Interfaces are often a point of failure for many transaction types. When interfaces result in transaction failures or data loss, subsequent downstream transaction links are jeopardized, clear audit trails are lost, process and sustainment costs increase (i.e., manual intervention to correct errors) and overall enterprise efficiency decreases.

The Army has determined the best management approach is enterprise management. Interfaces will be developed in close coordination with partner stakeholders throughout the program’s lifecycle to minimize risk and achieve best value for the Army’s investment in ACWS.

Additionally, per DoDI 5000.02, Defense Business Systems must certify that the need to tailor commercial-off-the-shelf systems to meet or incorporate unique requirements or unique interfaces has been eliminated or reduced to the greatest extent practical.

ACWS is one link in a larger procurement and financial process often referred to as the Procure-to-Pay end-to-end process. Due to the unique nature of Army procurement, there are mission-critical needs that span across the Army, DoD, and Federal agencies. The key regulatory and statutory policies that guide procurement operations are contained in the FAR, DFARS, AFARS, and policies set forth by OSD(AT&L) – DPAP (Defense Procurement and Acquisition Policy).

Implementing those policies requires electronic interfaces to both Federal-wide and DoD-wide enterprise services, along with a range of unique Army systems, notably core financial systems of record. The Federal Financial Management Improvement Act (FFMIA) dictates that all systems that perform acquisition-related activities maintain electronic interfaces with core financial systems for the purpose of receiving commitments and transmitting obligations with appropriate process controls in place to ensure adherence to relevant laws, regulations, and policies.

It is the goal of the ACWS program office to design, develop, test, and deploy all interfaces in such a way to as to:

• Minimize unnecessary complexity and redundant data entry

• Maximize the use of non-proprietary, open source standards and architecture

• Eliminate transactional errors across the Army enterprise

• Avoid unnecessary sustainment costs

The following guiding principles will drive interface development:

• Reduce redundant legacy system landscape:

o Move to a single system to allow the Army to replace existing PADDS, SPS, and

VCE interfaces to multiple systems by collapsing integration into a single solution

• Improve financial systems integration and the Procure-to-Pay process o Engage with financial system and functional stakeholders; develop ACWS to include “handshakes”

FOUO

Acquisition Sensitive

6 ACWS Interface Development Strategy Version 1.0 17 December 2015 o Support identification of process efficiencies of the GFEBS/LMP process

• Utilize DoD Enterprise Services and Data Exchange Standards o Clause Logic Engine, COR Tool, and GEX

• Leverage existing Army investments and COTS functionality to the greatest extent possible o Use COTS-provided interfaces (if available) to the greatest extent possible o Determine if Army or DoD systems can accommodate processes or requirements for some data elements, potentially reducing overall number of interface objects

• Expand solution to contingency contracting/secure environment contracting and grants-writing organizations o Host solution on SIPR-NET, integrate with GFEBS-SA o Develop interfaces to Grants-specific system partners

• Institute continuous process improvement methodologies to ensure interface development remains consistent with current and emerging best practices and standards.

With these principles in mind, ACWS intends to undertake a rigorous, incremental approach to interface development. This strategy document is attempt to provide context to the ACWS Requirements Traceability Matrix with additional details about each of the currently identified interface partners systems, their specific function or mission, their functional organization, and insights into the business process and how ACWS will integrate into the overall process. The goal is to provide potential ACWS solution vendors a better understanding of how the ACWS PMO and functional sponsor view the To-Be systems and process landscape. The current conceptual view of the systems landscape is depicted in Figure 1.

It is expected that the ACWS solution vendor will develop their own detailed list of “development objects” related to interfaces based on their knowledge of their core COTS product, their expertise in how it best integrates with external systems, and leveraging the work products of system blueprinting efforts (taking into account efficiencies gained through Business Process Re-engineering). These objects should guide development efforts and allow the ACWS PMO to monitor costs and contractor performance.

The “object details” noted in Appendix B are conceptual and for reference only; they should not be construed as specific design objects that cannot or will not be changed during the blueprinting efforts of the Risk Reduction phase or subsequent development build efforts. ACWS solution vendors are encouraged to offer creative solutions that will achieve greater efficiencies, minimize development and customization efforts, and ensure long-term sustainment cost are manageable.

Please note: the content of this document and appendices is based on the ACWS PMO’s current understanding of the To-Be systems landscape. Specific details about partner systems are subject to change based on emerging interface requirements, updates to laws, regulations, or policies, and partner system modernization plans.

FOUO

Acquisition Sensitive

7 ACWS Interface Development Strategy

Figure 1: Conceptual To-Be Systems Landscape

FOUO

Acquisition Sensitive

8 ACWS Interface Development Strategy Version 1.0 17 December 2015

1.1 Phased Approach

The ACWS PMO intends to undertake an incremental approach to interface development utilizing a consistent methodology for interface development.

1.1.1 Phase 1

MDD to Authority to Proceed #1 During this phase, ACWS will engage with all interface partner stakeholders to ensure schedules and funding for planned development activities align. Additionally, DASA(P) with the support of the PMO will sponsor a series of “Process Standardization” workshops. These workshops will be held in order to develop standardized processes across the Army. Stakeholders from interface partners systems and functional proponents will participate in the workshops. The goal is to have a set of deliverables in the form of high level, standardized Army process designs and initial concept of potential business rules to allow the ACWS system integrator to move rapidly from contract award into Risk Reduction activities.

1.1.2 Phase 2

Contract Award to Milestone B (Risk Reduction/Task Order 001) This phase will focus on functional and technical integration workshops with system partners in order to support development of a Build schedule that will allow ACWS to achieve Full Deployment within agreed upon cost, schedule, and performance constraints. A comprehensive understanding of all necessary development or configuration efforts should be an outcome of this phase.

The specific goals of the RR phase as it relates to interface development are:

o Determine the level of effort for all interface development efforts, including those offered as “out of the box” by the COTS vendor, to specifically include development objects (e.g., RICEFW), potential courses of action, and alignment to Build schedule o Building off the efforts of the Process Standardization workshops, continuing engagement with interface partner systems program, technical and functional SMEs to further refine process and design concepts, process controls, business rules, and a determination of discrete data elements and high level business process designs o Use Business Process Re-engineering and mature governance processes to pursue possibility of additional efficiencies and to minimize complexity wherever possible (to include detailed courses of action for addressing challenges)

FOUO

Acquisition Sensitive

9 ACWS Interface Development Strategy Version 1.0 17 December 2015

1.1.3 Phase 3

Milestone B to IOC This phase will involve the full analysis, design, build, test, and deployment of all interfaces necessary for ACWS to achieve IOC and any additional interfaces determined to be in-scope for IOC. This requires live interfaces to all Integrated Award Environment (IAE) systems, all DoD Enterprise Services systems, and at a minimum one Army financial system. It is anticipated that the Build phase(s) will require intensive cross-functional design and cross-program technical workshops.

1.1.4 Additional Development Phases (if necessary)

All system interfaces (if any) not delivered as part of the first build are required prior to ACWS achieving Full Deployment.

Figure 2: ACWS IOC and FD Roadmap

FOUO

Acquisition Sensitive

10 ACWS Interface Development Strategy Version 1.0 17 December 2015

1.1.5 Operations & Sustainment

Interfaces must be developed and deployed in such a way as to minimize long-term sustainment costs. One of the goals of the Interface Working Group (IWG) is to ensure an open line of communications between ACWS and interface partners to eliminate unnecessary development efforts due to changes in system operations.

1.2 Interface Partner Agreements

The ACWS program office and functional sponsor have engaged with all interface partners, from the earliest requirements development workshops and on-going through the Material Solution Analysis via Technical Interchange Meetings (TIMs) and continuing functional coordination. It is anticipated that these efforts will continue up through the Risk Reduction phase. The overall goal is to eliminate delays due to lack of communication or administrative bottlenecks. Two key areas of engagement include:

• To ensure adequate communication and understanding ACWS intends to enter into an understanding early with all external interface partners via an Interface Working Group (IWG) charter. The IWG charter will:

− Provide a basis for a common understanding of the requirements and anticipated level of effort

− Provide an adequate planning horizon

− Reduce schedule and resource risk by keeping an open line of communication

− Build confidence with leadership and stakeholders

• MOA/SIA Agreements: Early engagement with interface partners has provided the program office with a great deal of insight into requirements for agreements and development across the enterprise. Each partner system has a tailored approach to the types of agreements they require, when they require them, and if any additional funding will be required. It is the intention of the program office to work with all interface partners to produce the set of agreements that is acceptable to all parties and eliminates any unnecessary delays to ACWS development and deployment activities.

FOUO

Acquisition Sensitive

11 ACWS Interface Development Strategy

Figure 3: Interface Development and Agreements Conceptual View

FOUO

Acquisition Sensitive

12 ACWS Interface Development Strategy Version 1.0 17 December 2015

2.0 Integrated Award Environment & Department of Defense Enterprise Services Systems

The Integrated Award Environment (IAE) consists of the suite of Federal systems that support procurement related activities across the Federal government. The DoD’s Enterprise Services consists of a suite of systems that provide critical capabilities to all DoD contracting sites.

2.1 List of IAE & DoD Enterprise Service Systems

1. Federal IAE Systems:

a. System for Award Management (SAM)

i. Currently includes the subsumed capabilities of CCR, FedReg, EPLS, and

ORCA.

b. Additional IAE systems:

i. Federal Procurement Data System- Next Generation (FPDS-NG)

ii. Federal Business Opportunities (FBO or FedBizOps)

iii. Wage Determination Online (WDOL)

iv. Past Performance Information Reporting System (PPIRS)

v. Past Performance Information Reporting System (PPIRS-SR)

vi. Contractor Performance Assessment and Reporting System (CPARS)

vii. Electronic Sub-award Reporting System (eSRS)

viii. Federal Funding Accountability and Transparency Act Subaward Reporting System (FSRS)

ix. Federal Awardee Performance and Integrity Information System (FAPIIS)

x. Contract Manpower Reporting Application (CMRA) – This an Army-owned system but since it receives procurement instrument award data from FPDS- NG it is grouped in this category

2. DoD Enterprise Service Systems:

a. Clause Logic Web Service (CLS)

b. Contracting Officers Representative Tool (CORT)

c. Global Exchange (GEX)

i. Procurement Data Standard (PDS) Compliance Check

ii. Transmission of PDS award/mod files to MOCAS, EDA, iRAPT (WAWF), cASM, and SPOT

iii. Receipt of PDS award/mod files

iv. Receipt of contract mod files in ANSI X12 860 format (typically

Administrative Contracting Officer modifications by DCMA/MOCAS users)

v. Receipt of vendor invoice receipt/goods delivery, and government acceptance data from iRAPT (WAWF)

FOUO

Acquisition Sensitive

13 ACWS Interface Development Strategy Version 1.0 17 December 2015

vi. Receipt of Procurement Request Data Standard (PRDS) files from cASM

vii. Receipt of conformed contracts from EDA

viii. Transmission of contract closeout notifications to EDA

ix. Receipt of contract closeout notifications from MOCAS or EDA

2.1.1 IAE and DoD Enterprise Service Systems Considerations

1. The ACWS scope of work includes the analysis, design, build, test, and successful deployment to the ACWS production environment for all the systems in the IAE and DoD Enterprise Services.

2. Due to the fluid schedule of the consolidation of systems under the umbrellas of the System For Award Management, it is unknown at this time which systems will be part of SAM when ACWS is developed. As of this writing, only CCR, FedReg, ORCA, and EPLS have been consolidated into SAM. However, the current plan for future migration of systems to SAM calls for integration to the common SAM hosting enclave; the current understanding is that external interfaces will not be changed. DASA(P) has identified which systems will require direct data feeds and these are captured in systems landscape documentation.

3. During the Risk Reduction phase, an analysis will be conducted to determine the level of effort required to implement any COTS-provided IAE or DoD interfaces in the ACWS production environment.

a. Market Research conducted by the Army indicates that many vendors that offer Commercial-Off-The-Shelf (COTS) contract writing solutions have already designed and built interfaces to some of the IAE and DoD Enterprise Services systems. One of the planned activities of Risk Reduction is to determine what additional efforts, if any, will be required to integrate the COTS offered interfaces into the ACWS production environment.

b. During this phase, any additional development effort for IAE/DoD systems need to be fully understood down to the detailed development object level. The RR phase will validate if such efforts are necessary, determine development objects required, and align those efforts/objects with the appropriate Build.

2.1.2 IAE and DoD Enterprise Services System Descriptions

SAM

GSA’s Office of Government-wide Policy is consolidating federal procurement and award systems into one new system—the System for Award Management. SAM is streamlining processes, improving data quality by eliminating the need to enter the same data multiple times, and consolidating hosting to save taxpayer money.

SAM is being developed in phases. Phase I (live) includes the capabilities found previously in Central Contractor Registration (CCR), Online Representations and Certifications Application

FOUO

Acquisition Sensitive

14 ACWS Interface Development Strategy Version 1.0 17 December 2015

(ORCA), and the Excluded Parties List System (EPLS). This integration of capabilities streamlines the process of entity (e.g., vendors and grantees) registration and gives contracting and grants staff a single-source picture of who is eligible for awards.

Future phases are expected to include the capabilities found today in the Electronic Subcontracting Reporting System (eSRS)/FFATA Subaward Reporting System (FSRS), the Catalog of Federal Domestic Assistance (CFDA), Federal Business Opportunities (FBO), Wage Determinations On Line (WDOL), Federal Procurement Data System (FPDS), Past Performance Information Retrieval System (PPIRS), Contractor Performance Assessment Reporting System (CPARS), and Federal Awardee Performance and Integrity Information System (FAPIIS). The consolidation of these capabilities will further streamline processes for both government and awardees. However, at this time the consolidation will focus on integrating these systems within the common hosting enclave. This will streamline integration efforts but likely will not mitigate the need for direct interfaces between ACWS and relevant systems. Additionally, the interface designs will not be changing as to minimize disruption for existing customers. As with any modernization efforts, the SAM consolidation is a work-in-progress and the PMO will monitor those efforts for any cost, schedule, or performance impacts to the ACWS development efforts.

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.

FPDS-NG is the primary source of data for many “downstream” systems in the IAE. ACWS will rely on FPDS-NG to provide data to these systems and currently has no development efforts planned to send data to: FAPIIS, FSRS, ESRS, CPARS, PPIRS, PPIRS-SR, and CMRA. DPAP currently estimates that 40-50% of the required data elements for FPDS-NG can be automatically pre-populated from a contract; the goal would be to maximize the amount of pre-populated data in order to minimize manual data entry required for ACWS users as part of the FPDS-NG process. Additionally, all data captured by FPDS-NG related to ACWS procurement instruments must be captured as data and retained with ACWS.

FedBizOpps

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.

FOUO

Acquisition Sensitive

15 ACWS Interface Development Strategy Version 1.0 17 December 2015

WDOL

WDOL provides a single location for federal contracting officers to use in obtaining appropriate Service Contract Act (SCA) and Davis-Bacon Act (DBA) wage determinations (WDs) for each official contract action. The website is available to the general public as well. Current plans call for the development of an outbound data feed that will be available to contract writing systems to support contract creation and development. The As-Is process requires users to manually log into WDOL to retrieve wage data. The To-Be process should provide ACWS users with access to current wage data within the ACWS solution without the need to log in to WDOL directly.

PPIRS & PPIRS-SR

PPIRS is a web-enabled, enterprise application that provides timely and pertinent contractor past performance information to the Department of Defense and Federal acquisition community for use in making source selection decisions. PPIRS assists acquisition officials by serving as the single source for contractor past performance data. Confidence in a prospective contractor's ability to satisfactorily perform contract requirements is an important factor in making best value decisions in the acquisition of goods and services. PPIRS consists of two components, Report Card (RC) and Statistical Reporting (SR). (Note that PPIRS-SR is deployed only in DoD currently and is discussed separately earlier in this document.) Both components support the Federal Acquisition Regulation (FAR) requirement to consider past performance information prior to making a contract award (FAR Parts 15, 36 and 42). PPIRS receives contract data from FPDS-NG. Current plans call for the development of an outbound data feed that will be available to contract writing systems to support source selection activities. ACWS will require the ability to receive these data feeds via electronic interface.

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. Current plans call for the development of an outbound data feed that will be available to contract writing systems to support contract administration and close-out activities. ACWS will require the ability to receive this data feed via electronic interface.

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. eSRS receives contract data from FPDS-NG. There is no requirement for a direct interface between ACWS and eSRS at this time.

FSRS

FOUO

Acquisition Sensitive

16 ACWS Interface Development Strategy Version 1.0 17 December 2015

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. FSRS receives contract data from FPDS-NG. There is no requirement for a direct interface between ACWS and FSRS at this time.

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). FAPIIS receives contract data from FPDS-NG. There is no requirement for a direct interface between ACWS and FAPIIS at this time.

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.

CMRA receives contract award data via a feed from FPDS-NG. ACWS needs to receive the status report electronically from CMRA. CMRA is an Army system that has been grouped with the IAE systems because it receives data related to procurement actions via a feed from FPDS- NG. ACWS will only need to receive the status file produced by CMRA.

Global Exchange (GEX)

FOUO

Acquisition Sensitive

17 ACWS Interface Development Strategy Version 1.0 17 December 2015

The GEX provides 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 and receive award and modification files in the standard PDS format to GEX for downstream consumption by EDA, MOCAS, WAWF, and SPOT. ACWS is also required to be capable of sending and receiving files in the Purchase Request Data Standard (PRDS). Currently, the only system identified that sends PRDS files via GEX is cASM. Finally, GEX will also be used for ACWS to send and receive contract closeout notifications. ACWS will receive, via GEX, a contract closeout notification generated by MOCAS in ANSI X.12 EDI 567 contract completion format. ACWS will create and send via GEX completion notices also utilizing the ANSI X.12 EDI 567 contract completion status transaction set for distribution to EDA.

Procurement Data Standard (PDS)

The Procurement Data Standard (PDS) is a system-agnostic data standard that is intended to be adopted and implemented DoD-wide for creation, translation, processing, and sharing of procurement actions. It defines the minimum requirements for contract writing system output to improve visibility and accuracy of contract-related data, to support interoperability of DoD acquisition systems and to standardize and streamline the procure-to-pay business process.

Further, the PDS will improve visibility of contract-related data, enabling senior DoD leadership to make better informed business decisions. And finally, this data standard will support future migration to enterprise and federal systems and processes where appropriate. The PDS was developed under the guidance of the Defense Procurement and Acquisition Policy office (DPAP). Phase 1 was released in the third quarter of FY08. This version addresses contract awards. Future versions are intended to cover contract modifications and expand the data available within clauses and provisions. While PDS is not an external interface, the To-Be business process requires a “compliance validation” check utilizing the GEX. Prior to issuing an award or modification, ACWS must transmit a PDS XML file to GEX for validation.

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 currently developing the capability to send conformed contracts. All integrations with EDA will utilize the GEX.

FOUO

Acquisition Sensitive

18 ACWS Interface Development Strategy Version 1.0 17 December 2015

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.

Invoice Receipt, Acceptance and Property Transfer (iRAPT) formerly Wide Area WorkFlow

(WAWF)

iRAPT (formerly WAWF) is a secure web based system for electronic invoicing, receipt, acceptance, property transfers, and miscellaneous payment. iRAPT allows government vendors to submit and track invoices and receipt and acceptance documents over the web and allows government personnel to process those invoices in an on-line paperless environment. Likewise, it allows contractors and government personnel to create and track data on shipments of government property to and from vendors. As part of those capabilities, it is the point of capture for Item Unique Identification and Radio Frequency Identification. iRAPT is the only reliable electronic means of capturing delivery data for the logistics and property processes of the department. iRAPT meets the requirements of 2001 National Defense Authorization Act, which requires claims for payment under a Department of Defense contract to be submitted in electronic form. On March 03, 2008, DOD has issued a final rule amending the Defense Federal Acquisition Regulation Supplement (DFARS) to require use of the iRAPT as the only acceptable electronic system for submitting invoices and receiving reports under DOD contracts.

iRAPT is being enhanced to make use of the expansion in data available from EDA as a result of the PDS. This will further reduce data entry requirements, improving data quality. The newly redesigned iRAPT Management Reporting System enables the department to measure and collate data on contractor deliveries across the department, as well as providing reports for immediate use in managing payment processes. iRAPT is key to the future contract writing environment due to its ability to support transparent operations and prepopulate data from EDA regardless of where a contract action is issued. ACWS is required to send PDS files to iRAPT and retrieve data about deliveries, acceptance, and invoices from iRAPT. ACWS will exchange files (send and receive) with iRAPT via the GEX.

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.

Clause Logic

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

FOUO

Acquisition Sensitive

19 ACWS Interface Development Strategy Version 1.0 17 December 2015 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).

Mechanization of Contract Administration Services (MOCAS)

MOCAS is used for the management and payment of complex contracts. MOCAS supports the management and payment of contract financing payments, cost reimbursable contracts including management of funds and multi-funded contracts and line items. It provides capabilities for contract management including support to source acceptance on contracts requiring higher level or specialized quality assurance requirements, administration of Government property furnished to contractors, management of contractor business systems and contract closeout. MOCAS provides the Defense Contract Management Agency with an enterprise source of contract management data for all its Military Service and Defense Agency customers enabling them to be the single face to industry for Contract management. Payments from MOCAS account for approximately 60% of the dollars paid to vendors by the Department of Defense. ACWS will send award and mod files to MOCAS in standard PDS format via the GEX. Contract mods made by DCMA ACO’s will also come through GEX in ANSI X12 860 format. ACWS will also receive contract closeout notifications in ANSI X12 567 format from MOCAS, also via GEX.

Synchronized Pre-Deployment Operational Tracker (SPOT)

SPOT is a Web-based system that provides a standardized front-end user interface for use by federal contractors, government agencies, and the military. SPOT generates digitally signed Letters of Authorization (LOAs) as part of the deployment process for contractors. These LOAs have a unique SPOT barcode that identifies contractors who do not carry a government-issued Homeland Security Presidential Directive 12-compliant card. SPOT supports system integration with authoritative data sources, such as Federal Procurement Data System-Next Generation (FPDSNG) for contract information and Defense Manpower Data Center (DMDC) for personnel information, to validate user entered information and increase data quality. With movement data uploaded from JAMMS and integration with biometric and base authorization systems data, SPOT allows verification of a person’s identity in theater, tracks their movements, and provides theater commanders up-to-date visibility into contractor assets and capabilities. ACWS will send award data to spot utilizing the GEX and the standard PDS XML.

Contingency Acquisition Support Module (cASM) cASM is a Global DISA Hosted web-based system designed to support the Operational Contract Support (OCS) process for joint contingency or expeditionary environments including:

• Logistics planning module to develop a contingency statement of requirements (supports crisis action, exercises and deliberate planning)

• Requirements generation (interfaces with external Contract Writing Systems via the Defense Logistics Agency-Transaction Services (DLA-TS) Global Exchange (GEX))

• Web Reporting

FOUO

Acquisition Sensitive

20 ACWS Interface Development Strategy Version 1.0 17 December 2015

ACWS will receive PRDS XML purchase request files originating in cASM and transmit PDS XML award files to cASM utilizing the GEX.

3.0 Core Financial Systems

The Army contracting enterprise serves a wide range of customers and as such electronic interfaces to multiple financial systems are required. These interfaces must be designed and built in accordance with all relevant Federal Financial Management Improvement Act (FFMIA) requirements, as well as take into consideration all OSD/CFO and Army FM&C policies that are relevant to the Procure-to-Pay process. It is anticipated that integration with financial systems will represent the most complex and labor intensive efforts for ACWS development and will require a significant timeline to accommodate all analysis, design, build, test, and deployment efforts in conjunction with partner program offices and their respective functional proponents.

Additionally, due to the complexity of financial ERPs and their current sustainment or modernization efforts, there could be a significant lead time to coordinate development efforts (which typically include functional and technical workshops and joint design, build, and test activities).

ACWS requirements may vary slightly according each respective financial systems’ unique business process or technical maturity, but at a high level they all share the same common interface requirements:

1. Inbound Purchase Requests & Purchase Request Amendments (with funding)

2. Inbound Entitlement/Disbursement Data (to support contract closeout and reporting)

3. Outbound Procurement Instrument Award/Modification Files (Purchase

Orders/Obligation Postings)

4. Pre-Award Funds/Obligation Posting Check

5. Inbound Status of Goods Receipts, Invoice Receipt, and Delivery Status

ACWS Financial System Interfaces

1. General Fund Enterprise Business System (GFEBS)

2. Logistics Modernization Program (LMP)

3. Corps of Engineers Financial Management System (CEFMS)

4. Integrated Accounts Payable System (IAPS) & Automated Business Services System

(ABSS); and Defense Enterprise Accounting and Management System (DEAMS)

3.1 Considerations for Development of Financial Systems Interfaces

1. At a minimum, ACWS must be able to electronically integrate with at least one Army financial system to support achieving Initial Operational Capability (IOC).

FOUO

Acquisition Sensitive

21 ACWS Interface Development Strategy Version 1.0 17 December 2015

2. Integrations with financial systems will most likely require a series of analysis and design workshops in coordination with the ACWS solution vendor, ACWS program and functional SME’s, and similar resources from partner systems.

3. Interfaces with financial systems must meet all “feeder” or “mixed” system requirements of the Federal Financial Management Improvement Act (FFMIA).

4. The Risk Reduction phase will focus on high level interface characterization, from both a technical and functional business process perspective with a goal of developing a well-informed and executable plan. The interface-specific design, build, and test activities for will be undertaken during subsequent Builds.

5. Per existing policy, ACWS must be compatible with the Purchase Request Data Standard (PRDS). At this time, none of the ACWS partner financial systems transmit purchase requests in the PRDS format. The DEAMS PM stated in a preliminary planning meeting that they are moving towards adopting PRDS and PDS but no timeline was given for completion. On-going policy discussions between the acquisition and financial communities may dictate utilizing standard PRDS/PDS files and the GEX for all contracting and financial system integration, but at this time those policies have not been finalized and are subject to change.

6. The Pre-Award Funds Check/Obligation Posting Check interface is a tool to validate that any new awards or modifications will post correctly as obligations in partner financial systems and ensure the availability of funds. Along with building the interface to conduct the check, sufficient process controls and business rules should be included in solution and process designs to ensure users cannot release awards or modifications without running the check (with the possibility that exceptions may be required in certain scenarios with approval of users with authority to authorize such exceptions). Each financial system may have varying business rules that will need to be determined during initial blueprinting to ensure the Pre-Award Funds Check/Obligation Posting Check (also referred to as Handshake #2) satisfies all cross-functional requirements.

7. The Outbound Award/Modification interface is currently conceptualized as a direct, point-to-point to interface between ACWS and each financial system. However, policy changes and agreements with the financial community may result in movement towards a common standard, or the adoption of PDS XML award file utilizing the GEX.

8. The Army continues to experience a significant amount of posting errors in respective financial systems due to the inherent challenges of integrating ERPs in a larger end-to-end process. The ACWS solution vendor will be expected to provide recommendations to improve current processes and ensure that ACWS design decisions do not have a negative impact on financial system integrations.

9. Army contracting sites currently conduct business on behalf of Air Force customers and integration with Air Force financial systems is a requirement when fielding to those sites.

FOUO

Acquisition Sensitive

22 ACWS Interface Development Strategy Version 1.0 17 December 2015

Currently, ACWS requirements call for integration with two legacy financial systems, ABSS (for funding/accounting formation) and IAPS (for entitlement), and DEAM, the Air Force’s financial ERP. DEAMS, will likely subsume those systems but will not be assuming management for legacy contracts. ACWS may have to integrate with all three systems during a brown out period for IAPS and ABSS contracts.

10. ACWS has a requirement to deliver contract writing capabilities to those organizations that support classified requiring activities. There is a requirement for an ACWS to operate on the SIPRNET and to integrate with GFEBS-SA. Due to the complexity of operating business systems in a secure environment, it is anticipated that no other interfaces will be required for this operating mode. As GFEBS-SA is not an exact replica of GFEBS, it is unknown how much of the interface development between ACWS and GFEBS can be re-used. However, initial discussions with GFEBS-SA indicated that if the ACWS/GFEBS interface design efforts include GFEBS-SA SME’s then a full design and build effort might not be required for GFEBS-SA integration. Additionally, because GFEBS-SA is implementing a Cross-Domain Solution to allow electronic interaction between the SIPRNET and NIPRNET, there is a potential opportunity to leverage GFEBS-SA for additional vendor master and customer master data. Further analysis is required to determine potential opportunities to leverage the GFEBS-SA CDS.

3.2 Financial Systems Descriptions

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. GFEBS serves as the Army’s response to statutory and regulatory requirements including the Chief Financial Officers (CFO) Act of 1990, the Federal Financial Management Improvement Act, the Government Performance and Results Act, the Government Management Reform Act, the applicable accounting standards of the U.S. Standard General Ledger, the Department of Defense (DoD) Financial Management Regulation, multiple Office of Management and Budget Circulars, and DoD’s Business Enterprise Architecture (BEA).

GFEBS supports the CFO Act core financial system processes: general ledger management, financial reporting, real property, plant, and equipment accountability, reimbursables, revenue, and accounts receivable, cost management, funds control and budgetary accounting, accounts payable, and audit trails and system controls. GFEBS also brings the majority of Army financial and real property management processes into a single system, integrates performance data and produces full costs. This provides real-time visibility of transactions, access to financial accounting, cost and decision support.

LMP

The Logistics Modernization Program (LMP) supports the Army national-level logistics mission to develop, acquire, field and sustain the world’s best equipment and services, providing soldiers

FOUO

Acquisition Sensitive

23 ACWS Interface Development Strategy Version 1.0 17 December 2015 with a decisive advantage. LMP delivers an enterprise system for the Army Materiel Command (AMC) with a fully integrated suite of software and business processes, providing streamlined data on maintenance, repair and overhaul; planning; finance; acquisition; and weapon systems supplies, spare parts, services and materiel.

LMP Increment 1 is deployed to more than 50 locations with approximately 21,000 users throughout AMC and related major subordinate commands, depots and arsenals, as well as the Defense Finance and Accounting Service. With the implementation of LMP Increment 2, the system will have 9,000 new users and provide additional functionality to 5,000 existing users.

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.

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