Attch_0007_ACWS_CONOPS-OMS-MP_Final_Sign_2015_10_26.docx

ARMY CONTRACT

WRITING SYSTEM

(ACWS)

Concept of Operations (CONOPS) Operational Mode Summary (OMS) / Mission Profile (MP)

Version 1.0 26 October 2015

Prepared By:

Functional Sponsor for ACWS Deputy Assistant Secretary of the Army (Procurement)

ACWS CONOPS/OMS/MP

Version 1.0 26 October 2015

Distribution A: Approved for public release; distribution unlimited

This page intentionally left blank

APPROVAL PAGE

SUBMITTED BY:

APPROVAL:

Revision History

Table of Contents

List of Figures

List of Tables

ACWS CONOPS/OMS/MP

viii

Version 1.0 26 October 2015

Distribution A: Approved for public release; distribution unlimited

Executive Summary The Army currently operates, maintains, and supports two separate contract writing systems (Standard Procurement System (SPS) and Procurement Automated Data and Document System PADDS)) and several contract management, administration, and reporting tools, including those in the Virtual Contracting Enterprise (VCE) suite, and the Army Contract Business Intelligence System (ACBIS). This redundancy in systems leads to more complicated business processes; increased operational, maintenance and support costs; more complex interfaces and integrations; and limits the Army’s ability to rapidly expand the contracting enterprise in support of contingency/combat operations. The Army requires a single uniform solution for contract writing, management, execution and close-out capabilities in an integrated architectural environment that will enable the acquisition of systems, goods, and services for Soldiers both in garrison and in deployed environments. Furthermore, the Army intends to establish a streamlined contract writing data-centric environment that captures data at entry source and shares it with authorized users and other systems as appropriate resulting in improved reporting, monitoring, and administration.

This concept of operations lays out the structure and interactions that will be encompassed within the Army Contract Writing System (ACWS) solution, the organizational support elements required to develop and deploy the solution, and the functional scenarios in which the solution will be expected to operate.

Vision and Objectives Vision Deliver a world-class ACWS that uses modern technologies to allow for customized workflow, on-demand collaboration, and rapid adaptability to frequent changes in regulations, policies, and procedures using centralized services, standardized business rules, and standard data schemas.

Objective The Army’s objective is to streamline contracting end-to-end business processes; reduce complexity; promote and improve efficiencies when integrating with existing ERPs; and minimize operating, maintenance and support costs. As a financial feeder system, ACWS will meet the compliance requirements of the Federal Financial Management Improvement Act (FFMIA) of 1996. ACWS will support the full spectrum of the Army’s contracting end-to-end business processes resulting in a single contract writing and management solution that supports financial auditability. An integrated architectural environment will enable the acquisition of systems, goods, and services for Soldiers both in garrison and in deployed environments, combat or non-combat contingencies, CONUS and OCONUS, as well as secure and non-secure environments. The system will provide the capabilities that support supply, service, major systems, research and development, information technology, Foreign Military Sales, contracting, grants and assistance agreements, and Other Transactions. Furthermore, the Army intends to establish a streamlined contracting environment that captures data at entry source and shares it with authorized users and other reporting databases as appropriate resulting in real-time acquisition reporting and improved contract monitoring and administration.

The Army Contract Writing System Concept The ACWS concept includes key management and administration capabilities in addition to the creation of procurement instruments inherent in a “contract writing system.” The functional system requirements for the ACWS encompass the elements depicted in Figure 1. This concept model provides the operational context in which the capability requirements are expected to be satisfied.

Figure 1: ACWS Concept ACWS Program Operations and Support This section of the ACWS concept of operations focuses on the operational elements that are in place to support the program. Supporting elements include the people, processes, and operations that ensure the successful execution of the ACWS program.

Program Support Overview ACWS will be supported by numerous entities throughout the Army, DoD, and the Federal procurement environment. Figure 2 below provides a high-level view of the primary organizations and the functions they perform.

Figure 2: ACWS Program Support Framework Stakeholder Management ACWS has many stakeholders outside of the Product Management Office (PMO) and Functional Sponsor. Each of the stakeholders identified in Figure 3 below perform different supporting roles and will have priorities and recommendations based upon their function. The ACWS program must consider all of the input from the larger community and manage accordingly. Consistent and timely communication to stakeholders at every level will be critical to manage expectations. Specifically, outreach to the Army Contracting Enterprise (ACE) will be necessary to ensure that the program delivers a solution that satisfies requirements and provides superior support to the Army.

Figure 3: ACWS Stakeholders Functional Governance The Procurement Systems Governance Board (PSGB) sponsored by the Office of the Deputy Assistant Secretary of the Army (Procurement) (DASA(P)) retains final approval authority for all contract/grants/agreements writing and management functional capabilities. The DASA(P) Capabilities Management Office (CMO) is responsible for developing any new functional requirements and coordinating the approval of those requirements through the PSGB governance process. The PSGB has approved the ACWS Baseline Functional Requirements and must be consulted should any deviation from that baseline be required.

The PSGB is a General Officer/Senior Executive Service (GO/SES) level board with a designated representative from each of the Army Buying Commands. The PSGB adheres to the processes and standards dictated by the Acquisition Domain Governance Board, chaired by the Principal Deputy for the Assistant Secretary of the Army (Acquisition, Logistics and Technology). The Functional Governance Structure is depicted in Figure 4:

Figure 4: Procurement Systems Functional Governance Structure Program Execution The ACWS Product Management (PdM) Office was established to manage and support the ACWS program throughout its life cycle. The ACWS Program Operations, depicted in Figure 5 below, are supported by a continuous process of evaluating the product strategy, designing, and developing a solution to accomplish this strategy; managing the various operational changes required to deploy the solution; operating the solution in the production environment; then using the lessons learned from those operations to re-evaluate the original strategy. The tasks, personnel, policies, and resources associated with these operations all work towards the successful execution of the application in its operational environment.

Figure 5: ACWS Program Operations The ACWS must conform to the mandates of FY10 NDAA Section 804. As prescribed by this Act, the Army must ensure: “(A) early and continual involvement of the user; (B) multiple, rapidly executed increments or releases of capability; (C) early, successive prototyping to support an evolutionary approach; and (D) a modular, open-systems approach.” (Source: FY10 National Defense Authorization Act, Section 804). The design and development model depicted in Figure 5 above) provides a visual framework for a FY10 NDAA Sec 804 compliant product operational schedule, shown in Figure 6 below.

Figure 6: FY10 NDAA Sec 804-Compliant Product Operational Schedule Table 1 below contains the key actions the Army must take to be NDAA Sec 804-compliant.

Table 1: FY10 NDAA Sec 804 Activity Descriptions

Mission Support Description The Mission Support Description provides information from a user-oriented perspective of how support services for ACWS will be organized and delivered. Mission support for the ACWS program will be provided using a mix of Functional and Technical Subject Matter Experts (SMEs) from three organizational components – The System Integrator (SI), the Government’s enterprise-level organizations ( PdM ACWS and the DASA(P) CMO), and by the local SMEs located throughout the ACE’s contracting offices. While the existence of these support elements will remain constant throughout the life of the ACWS, the amount of support each organization will be expected to provide will shift as the program moves through its life cycle. Figure 7 below illustrates how the majority of support will shift from the contractor and the ACWS enterprise government groups to the contracting systems support offices over time.

Figure 7: ACWS Life Cycle Mission Support Note: CME is Contract Manpower Equivalent In order for the above model to work, the Government must invest in the development of SMEs both at the enterprise-level as well as the local site level. This must be addressed as a critical change management function during the initial product development. In addition, the SI must be allowed (and encouraged) to transition knowledge and program support capability to the Government SMEs.

ACWS Service Model Strategy The primary driver for mission support operations will be the management of help calls received from the field. The ACWS support operations will require both Functional and Technical support. Basic functional support will be satisfied primarily by the contracting systems support groups located in the contracting office or in that office’s chain of command.

The ACWS Service Model promotes “self-help” whenever possible, and will leverage Government SMEs to the maximum extent possible. With support from the SI, the Government will develop and manage a multi-tiered help desk that provides continuous services for all environments. The 300 SI-trained Government SMEs will provide help desk services. Help Desk Services will be provided in three tiers as depicted in Figure 8 below.

Figure 8: ACWS Help Desk Service Model Tier I Support Tier I support starts at the local site and with the ACWS end user. This tier will be funded by DASA(P) and staffed by Government SMEs located at the local contracting office. Each end-user will report potential ACWS incidents to their Local Government SME for validation. It is anticipated that there will be 270 Government personnel that will be trained to perform the Tier I function. Each Army Contracting location’s dedicated Local Government SME will serve as the first line to rule out site-specific policy (functional) or infrastructure (technical) issues, and will take appropriate steps to resolve the reported problem. Ideally, the SME’s at this level will also capture/track data for these issues.

If the incident persists, the SME acts as the site’s “authorized user” and will submit the incident via phone call, email, and/or the Help Desk Management System for further analysis. The Help Desk Management System will be a Web-based, non-proprietary, incident/case management and customer relationship management system. The SME either directly (or indirectly) enters the relevant information into the system via the DASA(P) Knowledge Management Portal for further analysis. The Local Government SME will make an effort to determine appropriate incident priority (according to written criteria), and categorization (i.e., functional or technical) at the time of incident submission.

Provided and managed by the SI, the Help Desk Management System will be configured to allow unrestricted Government access and use to all data collected in conjunction with ACWS.

Tier II Support ACWS Tier II is divided into two support groups that handle incidents once they have been validated by a site’s authorized user.

Tier II Functional Support The Tier II Functional Support Group includes 30 Government ACE personnel (in addition to the 270 ACE personnel supporting Tier I) who will serve as a centralized cadre of functional personnel who will be trained to resolve Business Process and/or Functional ACWS issues. The Functional Support Group (FSG) will resolve incidents by ensuring end users are using the software as designed and in accordance with the business process; investigate root causes of systemic issues/incidents; update appropriate documents based on lessons learned from the incident report (e.g., CONOPS, Change Management Process, Knowledge Management Portal); and transfer unresolved incidents and information to the next level when required.

Tier II Technical Support The Tier II Technical Support Group includes dedicated contractor staff managed by the SI under the oversight of the ACWS PMO. The Technical Support Group addresses user-identified technical problems.

Tier III Support The Tier III Technical Support Group consists of dedicated system development resources from the SI. Tier III support is the last line of defense for the escalation of ACWS incidents.

Operations and Support The ACWS goals for Operations and Support are:

· Successfully transition Army Contracting personnel from their “As-Is” (current) business processes to the “To-Be” (future) set of processes to execute the Army Contracting mission

· Develop an Army-wide change management strategy to address strategic communication, user collaboration, cross-domain training, comprehensive knowledge management and overall marketing for the ACWS program

· Focus on developing and presenting frequent and effective workshops targeted toward executives, mid-level managers, and end-users to facilitate a successful transition to ACWS.

The Army contracting environment is constantly changing and adapting to meet the needs of the warfighter, adhere to demands from Legislative and Executive mandates, and respond to frequent regulatory and policy changes. The ACWS is expected to rapidly adapt to these changes in regulations, policies, and procedures using centralized services, configurable business rules and processes, and by making continuous improvements to the configurable elements of the solution platform. The concept of continuous process optimization should be employed to assess performance information, identify any potential or actual deficiencies, evaluate the potential opportunities for cost savings or other improvements, and apply product enhancements in the solution throughout its entire product life cycle – including in sustainment.

In this manner, the ACWS will not be a one-time development of a predetermined set of static requirements. The ACWS must provide a platform that will allow the Army to configure, reconfigure, adapt, and extend the initial solution in order to continue to serve as a single platform for automating contracting business processes. As such, operations and support processes, tools, and specialized code must be well documented and transferred to the Government in accordance with the data-rights specified in the contract.

Relevant Regulations, Policies, and Procedures The Federal Acquisition Regulation (FAR), Defense Federal Acquisition Regulation (DFARS), Army Federal Acquisition Regulation Supplement (AFARS) as well as Department of Defense Grant and Agreement Regulations (DoDGARs) and local policies/procedures form the basis of all of the business rules, processes, and standards that the ACWS must adhere to in order to obtain and maintain a suitable operational readiness state. These regulations are living documents that are constantly in a state of change. Consequently, the system must be capable of adapting in a relatively short timeframe to regulatory changes without compromising the long-term sustainability of the end-product.

Additionally, the ACWS is guided by the following doctrine:

· Strategic Plan for Defense wide Procurement Capabilities (A Functional Strategy) Version 2.0, September 25, 2014

· DUSD Updated Procurement Functional Strategy Memo, September 2014

· FY13 NDAA Sec. 862 Uniform Contract Writing System Requirement

· USD(AT&L), Data Capture in Support of Contingency Planning, January 26, 2012

· Procurement to Pay 9.0 Business Enterprise Architecture, February 22, 2012

· USD(AT&L) SPS Sunset Memo, October 21, 2011

· USD(AT&L) DoD Contract Writing and Administration Capabilities, October 21, 2011

· USD(AT&L) Defense-Wide Contract Clause Logic Capability, August 31,2011

· USD(AT&L) DoD Compliance Roadmap for Existing and Future Contract Writing and Administration Capabilities v1.0.1, June 15, 2011

· DoD Operational Suitability Test Criteria for Contract Writing Systems (CWS), V0.3, April 29, 2011

· DUSD A&T Memo-Publication of Procurement Data Standard, (Phase I), July 21, 2008

· DUSD A&T Memo-Publication of Procurement Data Standard, (Phase II) July 31, 2009

· USD Memo- Linking Financial Data to Contract Data March 18, 2009

· Financial Data in Procurement Concept of Operations (FDIP CONOPS), December 15, 2008 Expectations

· The ACWS production environment will be in a Government-owned and Government Operated Data Center. Initial deployment will be in a NIPRNet domain with subsequent capabilities in a SIPRNet domain. Service Level Agreements (SLA) will cover Continuity of Operations (COOP) services for data protection, backup, and recovery.

· There are COTS products, with a variety of mature technology implementations, which meet the majority of ACWS requirements OOTB. These implementations, most of which are currently operational in federal agencies, range from systems that are turn-key, highly configurable, or those requiring custom development.

ACWS Operational Events Overview of Operational Events Operational events in the contracting domain are traditionally considered to follow the time-phased model depicted in Figure 9 below:

Figure 9: Traditional Contracting Process The entry point in this process, the steps required within this process, and whether or not the action requires an individual closeout function is a function of the Procurement Action type and Procurement Method combination. These Operational Rules are defined in the ACWS Operational Rules Matrix included at Appendix D.

From left to right, the high-level operational events that this model depicts are further described at a high level below (Detailed requirements can be found in the Requirements Traceability Matrix (RTM).

A condition that warrants a Procurement Action is discovered, determined, or otherwise revealed. A valid requirement is identified.

· The Contracting Officer (KO)/Specialist coordinates with the Requiring Activity, Vendor(s), Legal, Administration Office, or any other pertinent offices to elevate the condition from a concept into a suitable requirements package. Based on the source of the condition, a Purchase Request (PR) and/or Requirements package is prepared in a customer’s business system or the KO/Specialist initiates an administrative action.

· The Contracting Office receives the PR Package and/or PR from the Requiring Activity via the PR System or DASA(P) KM Portal.

· Upon acceptance of the Requirements Package, a Procurement Action Record is created and workload is assigned. Alternatively, a Procurement Action Record may be created by the KO/Specialist and the Requirements Package may be associated to the existing record.

· The Procurement Action is characterized by coding it with a specific Procurement Action / Procurement Method code combination as specified in the Procurement Action / Procurement Method table (Operational Rules Matrix). Based upon user input of these attributes, the system/user will define the milestones/activities required to complete the Procurement Action.

· The KO/Specialist inputs data into the Procurement Action Record. The record consists of 5 parts: the Electronic Official File (EOF), Procurement Instruments, Procurement Process Data, Workflows, and various standard Forms or Templates. System processes are initiated to generate the data and associated outputs required for these parts of the Record and data from all parts are used to support elements of other parts.

· Notices and Solicitation information is published to FEDBIZOPPS (FBO)/ Vendor Portal using data from the Procurement Action Record.

· Vendors receive information from and submit data into the Vendor Portal. That data is then incorporated into the Procurement Action Record as well.

· Depending upon the Procurement Action / Procurement Method chosen, various evaluation tools may be used to automated elements of the source selection proceedings associated with the Procurement Action.

· The Procurement Action is finalized generating the award instrument and sending the award and obligation data back to the customer’s requirements generation system as well as to down-stream P2P entities. Downstream data distribution occurs via the Global Exchange (GEX).

· The Procurement Action is managed/administered including receiving inputs from Customers, COR’s, Vendors, DFAS/DCMA, and Contracting. As activities are recorded in financial management, entitlement, or logistics systems, those data warehouses are accessed to display performance data to the KO/Specialist. This administration may initiate other Procurement Action(s).

· Various status/milestone updates are provided to the requiring activity via notifications/interfaces.

· Eventually the Procurement Action reaches its end of life, at which point it is closed out, goes through a Records Retention period, and then is purged.

· Data developed throughout the execution of system processes is recorded in the Procurement Data Warehouse which is accessed via a Business Intelligence portal.

Note: Although the above depicts a traditional contracting process, we anticipate a similar process albeit some different terminology, for grants and cooperative agreements.

Capabilities Models and Descriptions ACWS is expected to contain all the functional capability necessary to accomplish the full spectrum of Army contracting processes. Figure 10 depicts the ACWS design concept and major system features.

Figure 10: ACWS Conceptual Resource Flow Design Concept (OV-2) With this high-level operational model in mind, the following sections provide greater details on the actual transactions, interfaces, business views, and data views that are anticipated.

User Interface Transactions Table 2 below lists of typical user interface transactions that are anticipated to be accomplished in the ACWS. How these transactions are characterized or described will vary based on the capabilities of the underlying platform, but should accomplish the same intent of the transactions listed below. Detailed requirements for Interfaces can be found in the Requirements Traceability Matrix (RTM).

Table 2: User Interface Transactions Anticipated in ACWS User Interfaces

Review/Accept/Acknowledge an incoming requirements package

Receive/Accept/Acknowledge an incoming purchase request (funding document)

Associate incoming purchase requests (PRs) and requirements packages to a Procurement Action Record (add to existing or create a new Record based on the acceptance of the PR/Package).

Receive and import data from excel spreadsheets (1-N list, project listing, spend plans, etc.) to track and manage procurement planning and forecasts

Track contract periods of performance (PoP) and funds obligated against the PoP for the purposes of tracking incremental funding actions (Instrument and CLIN)

Establish pre-defined customer oriented notices (status, progress, pending, received, etc.) for an individual document , action or package

Establish Contract Milestones and/or Workload Priorities

Establish and Integrate PALT standards across the contract phases and provide a visual display corresponding to status indicators

Manage Congressional and Audit Activities associated with singular procurement activities, findings, results, corrective action plans and organizational self-assessment requirements

Incorporate DASA(P), PMR, HQ, local level checklists and toolkits into the relational data fields

Create/Update a Procurement Action Record

Differentiate between pre and post award actions

Establish the framework for the Electronic Official File.

Create/Update/Upload Documents into the Electronic Official File.

Enter/Update Procurement Action MetaData (e.g., Assign/Reassign Workload, Add/Edit Milestone Data, Enter status comments, record protest data, etc.)

Assign/reassign workload and retain assignment history throughout the full life cycle process

Create/Update a Procurement Instrument

Search individual records for procurement status using a single or multiple descriptors

CAC-enabled, digitally sign an instrument or document

Initiate a Workflow – both standardized and ad hoc

Execute a Workflow Task (Review, Edit, Comment, Approve/Reject, etc.)

Establish distributions lists

Distribute contract actions using the distribution list

Publish a Notice to the Vendor Portal

Publish a Notice to FBO

Publish information to Grants.gov

Create/Submit a Proposal (Vendors) via the Vendor Portal

Associate child Procurement Action Records to a parent/basic Procurement Action Record (e.g. Procurement Action Records for more than one award can be associated with a single Multiple Award Contract/Program)

Receive and track delivery, receipt, contractor receipt of GFP, acceptance and payment information

Incorporate the management of protests, claims, appeals, etc.

Incorporate and monitor progress towards small business and competitions goals

Import foreign exchange rates from authoritative source

Synchronize from a disconnected instance (including resolving sync errors)

Administration Transactions: User setup, business rule administration, automated workflow process flow setup a new business process, etc.

Business Intelligence Reporting (generate reports, dashboards and report cards)

Facilitate the Contract Closeout process, to include records retention.

Execute integrity and validation checks anytime for draft contract actions

Establish and update correct contract clauses based upon contract action attributes

Establish and update terms and conditions based upon grant/agreement attributes

Access Help capabilities such as guides, manuals, FAQs, etc.

View and respond to notices, system alerts, update notices, and related system generated messages.

Bulk load of line item data

Receive/bulk load planning data such as spend plans, 1-N lists, etc.

Systems Interface Transactions In addition to user interface capabilities, the ACWS must have the ability to operate in an integrated business systems environment. This environment is depicted in Figure 11 below:

Figure 11: ACWS High-Level “To-Be” System Interface Description (SV-1) Given the environment depicted above, Table 3 lists the system interface transactions that are anticipated in ACWS Table 3: Anticipated ACWS System Interface Transactions System Interface Transactions

Receive PR/Requirements Documents and import data into separate fields

Receive and import planning and forecasting data (spend plan, 1-N lists, etc.)

Send notices/announcements

Send Justification and Approvals

Send Solicitations

Send public posting information (grants/agreements)

Receive Vendor Questions, provide Answers, and receive Proposals/responses

Funds Validation/pre-award check/control of period of performance (Handshake 2)

Send/receive acknowledgements (positive and negative)

Send PR/PR Package/Document , Instrument progress/status and updates

Clause Logic (Send indicators, View/adjust clause results in Clause Logic, Save output)

Vendor Master Data (Send CAGE, DUNS, receive/save Address, Reps, and Certs)

Validate Vendor data prior to award

Receive contractor qualification and eligibility Data

Receive and import wage determination

DoD Address Master Data (Send DODAAC, receive/save Address from authoritative source)

Validate appropriate DODAAC data

Contract Action Report (create, validate, and send data, view/adjust CAR, save output, send finalize message upon award)

Grants/Agreements Report (create, validate, send data, view/adjust, save output, send/ finalize message upon signature)

Send Award/Amendment Data (Send PDS and PDF)

Send Grants/Agreements Data

Send FMS Contract Data

Inspection/Receipt/Acceptance/Delivery/Payment/GFP/GFP shipping/disposition Data (Send Contract Number, Receive Delivery/Payment Data)

Receive closeout notification

Send completion notice

Send Government Furnished Property Data with award instrument

Procurement Data Warehouse (Send Procurement Action Meta Data at designated intervals)

Official File (Store everything in an Army-specified structured framework)

Policy Links (Link to external policy sites)

Periodic data loads to a Procurement Data Warehouse

Transmission of official records to a certified records management system (until ACWS obtains certification as a records management system).

User Roles ACWS will be deployed, operated, and maintained by users in the contracting offices located across the globe. A description of the various User Roles associated with the ACWS is provided in Table 4 below:

Table 4: ACWS User Roles

Supervisor/ Team Lead An elevated privilege role which allows the user to assign, reassign, and view workload across multiple Users. Supervisor/Supervisee designations are expected to be identified as a user profile characteristic.

Business Intelligence Analyst A user role that allows an individual to access Business Intelligence reports made available by Business Intelligence Administrators. Users in this role may also create and store reports in a location accessible exclusively to themselves (i.e. a personal folder) and send a stored report to another Business Intelligence Analyst who may elect to save that report in their personal folder.

Requirements TBD.

Requirements TBD.

Requirements TBD.

Requirements TBD.

Information System Security Manager (ISSM)* Role reserved for continuously monitors the system or information environment for security relevant events and configuration changes that negatively affect security posture.

Requirements TBD.

DoD COR Tool

*These roles are not included in the number of anticipated ACWS users.

Operational Modes The use of the terms “mission” and “operational mode” are interchangeable since they both serve to facilitate a common understanding of how the commander broadly intends to operate. An Operational Mode or Contracting Mission can be viewed from different perspectives given the diversity of operations across the ACE. These perspectives include alignment with a customer’s mission, alignment with Joint forces, alignment to the functional activities within the contracting office, and alignment to the regulatory body governing the activities being accomplished. Each of these is described in greater detail below.

Operational Mode Descriptions ACWS is expected to be deployed as a single solution that will support all of the Operational Modes employed throughout the ACE. The solution should provide consistency in appearance, utilization, and business rule implementation.

Each operational mode brings with it the potential for unique configurations that may be required. Table 5 below provides high-level information regarding the functional configuration considerations that must be made given the Operational Modes the ACWS will support.

Table 5: ACWS Operational Modes and Considerations

(1) Maintenance, overhaul, repair, servicing, rehabilitation, salvage, modernization, or modification of supplies, systems, or equipment.

(2) Routine recurring maintenance of real property.

(3) Housekeeping and base services.

(4) Advisory and assistance services.

(5) Operation of Government-owned equipment, real property, and systems.

(6) Communications services.

Foreign Military Sales Acquisitions for foreign military sales (FMS) under the Arms Export Control Act (22 U.S.C. Chapter 39). Section 22 of the Arms Export Control Act (22 U.S.C. 2762) authorizes DoD to enter into contracts for resale to foreign countries or international organizations.