EOP CMS Sources Sought Functional Requirements.pdf
PDF 183 KB Posted
- Solicitation number
- EOP-OAS-SS-22-0001
- Issued by
-
Executive Office of the President
View the file
Other files
| File | Type | Posted |
|---|---|---|
| EOP CMS Sources Sought.pdf | ||
| EOP CMS Sources Sought Key Capabilities Matrix.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
The Executive Office of the President
Office of Administration
Enterprise Contract Lifecycle Management Solution
Requirements Document
02-04-2022
1.0 BACKGROUND
2.0 GOALS
3.0 SCOPE
4.0 ASSUMPTIONS
5.0 FUNCTIONAL REQUIREMENTS
5.1 EOP Enterprise Contract Lifecycle Management
5.2 Document Management
5.3 Compliance Management, Alerts and Notifications
5.4 Government Purchase Card (GPC) File Management
5.5 Contract Search
5.6 Analytics and Reporting
6.0 TECHNICAL REQUIREMENTS
6.1 Application Integration
6.2 Role-based Access Control (RBAC)
6.3 Hosting
6.4 Data Management
6.5 Security, Auditing, and Encryption
1.0 BACKGROUND
The Executive Office of the President (EOP), Office of Administration (OA), Procurement and Contract
Management Division (PCMD) seeks to implement an Electronic Contract Lifecycle Management
System to support automated processes for enterprise contract file storage, workflows, document management, and records management.
PCMD supports approximately 14 EOP components and entities, and has roughly 20 Contracting
Officers and Contract Specialists, who execute approximately 550 contract actions and over 6000
Government Purchase Card (GPC) transactions each year. Additionally, there are several hundred staff involved in various procurement activities such as requisition preparation and approval, contract management, funds management, or other Government oversight tasks. PCMD estimates that the total number of concurrent users on this system could be as high as 500 during the end of fiscal year surge.
EOP currently uses disparate manual processes that rely on a patch-work of tools not designed for contract management. Staff must respond to the needs of the fast-paced and dynamic EOP environment using processes that are labor-intensive and cumbersome.
PCMD is seeking a contract lifecycle management system that will improve contract cycle times through automated workflows, collaborative reviews, metrics and reporting, efficient searches for archive contracts and a repository for filing procurement action documents, and electronic signatures.
2.0 GOALS
The goal is to have a contract lifecycle management system that automates and streamlines contract processes during key stages. These stages include: initiation, development of requirements, process and workflow, negotiation and approval, execution, ongoing management and compliance (within the secure contract repository system), and contract renewal.
Additionally, the solution should encompass qualitative and quantitative information and contract tracking capabilities.
• Enable staff to seamlessly and efficiently administer the entire acquisition lifecycle
• Improve productivity by providing uncomplicated, integrated, centralized, and automated processes
• Support compliance with federal procurement and financial management regulations
• Help staff plan and manage their work (i.e., task alerts, workflows, work queues)
• Facilitate collaborative reviews and sign documents with e-signature
• Run comprehensive reports (i.e., scheduled reporting on a recurring basis and ad hoc reporting) https://www.cobblestonesoftware.com/blog/contract-tracking-mastering-contract-management-series https://www.cobblestonesoftware.com/blog/contract-tracking-mastering-contract-management-series
3.0 SCOPE
• The system shall provide functionality for the full acquisition lifecycle of EOP procurement actions executed by PCMD on behalf of all Presidential Records Act (PRA) and Federal
Records Act (FRA) components within the EOP
• The system shall provide workflow and storage for all EOP GPC transactions, e.g., GPC documents, files, and reports
• The system shall provide functionality for all EOP Contracting Officer Representatives (COR), e.g., COR Designation Letters, COR Files, COR Monthly Status Reports
• The system shall provide integrated, automated processes for workflows, procurement portfolio data, and interfaces between documents
• The system shall provide a mechanism for integrated procurement action document filing and workload tracking.
• The system shall provide a mechanism for assigning and updating workloads while automating routing and approvals at certain acquisition milestones.
• The system shall be customizable and expandable (i.e. modular) to accommodate and synchronize with future needs, developments and applications.
• The system shall introduce the use of Robotics Process Automation (RPA) technology and artificial intelligence.
4.0 ASSUMPTIONS
• The data stored within the solution will be secure and subject to the PRA of 1978, 44 U.S.C.
§2201-2209.
• All internal email or change features shall be turned off or go through EOP exchange.
• The system will be On Premises or EOP will need control of the Encryption Keys.
• The system will be software multitenancy and all users will not necessarily have the same access privileges.
5.0 FUNCTIONAL REQUIREMENTS
5.1 EOP Enterprise Contract Lifecycle Management
a. The system shall enable users to organize, track, and automate the federal acquisition lifecycle.
b. The system shall provide comprehensive procurement process workflows for collaborative reviews and approvals, with a full audit trail.
c. The system shall provide the ability to sign documents using e-signatures (see
“Application Integration”).
d. The system shall enable different stakeholders to collaboratively author acquisition packages and associated procurement documents and include customizable approval functionality.
e. The system shall enable monitoring and notification of upcoming milestones, deadlines, need by dates for procurement actions in order to enforce their obligations.
f. The system shall provide work queues for both task assignees and those overseeing a task.
g. The system shall provide workflows and approvals from various milestones of an acquisition process (i.e., Component validation of the requirement; approval of the requirement through Request for New Solutions, if applicable, funding certification, Office of General Counsel Approval, Contracting Officer Approval, Higher Level
Reviewer Approval) and measure cycle times for each workflow stage.
h. Manage data migration support to/from legacy systems to/from new systems/applications to ensure smooth transitions, where applicable.
5.2 Document Management
a. The system shall provide searchable, centralized acquisition management and repository where all documentation related to a contract or agreement are stored and accessed from a single location according to user role and permissions.
b. The system shall provide siloed data for each specific EOP Component allowing only authorized staff to be able to access, view, approve, etc. for their specific offices.
c. The system shall provide the ability to scale data storage to permit an unlimited quantity of procurement related documents.
d. The system shall provide the ability to automate the filing of finalized procurement documents that have been approved to the appropriate procurement action file (i.e., completed and final approved acquisition package documents, approved requisitions).
e. The system shall provide the ability to upload, add, edit and remove various documents within the system through a drag and drop or upload function.
f. The system shall provide the ability to attach documents to contract records.
g. The system shall provide the ability to update and audit track file naming conventions as appropriate, and support unique identifiers (contract/order number and Title), containing an unlimited number of characters. For example:
11316021DXXXXEOP/11316021FXXXXOAS
h. The system shall support procurement document development by providing users the ability to author procurement documents from pre-approved templates and clauses/terms and conditions that reside in a template library.
i. The system shall support automated interfaces within a particular procurement action to interface common data between various documents.
j. The system shall provide pre-built Government-specific templates that are customizable.
k. The system shall allow users to store standard procurement templates
l. The system shall offer the choice between using drag & drop or file upload to add content to the template library.
m. The system shall allow role-based editing of template library contents.
n. The system shall provide comprehensive version control that stores different full version copies of the same contract, and provides an audit trail with edit history (i.e., name and date of persons who edited).
o. The system shall provide file and document export functionality for general users, in addition to system-level export of complete contract packages (objects) and the whole system. See “Technical Requirements: Data Management”
5.3 Compliance Management, Alerts and Notifications
a. The system shall provide the ability to monitor acquisition milestones by tracking important events such as periodic review dates, contract/order expiration dates, upcoming option period dates, contract/order closeout dates and contract staging dates.
b. The system shall provide the ability to configure and send automated system alerts, email, and calendar notifications for acquisition milestones.
c. The system shall provide the ability to send automated system alerts, email, and calendar notifications sent through EOP’s email system to personnel’s email addresses associated with a contract/order regarding acquisition milestones requiring action.
d. The system shall provide the ability for users to monitor acquisition commitments and report any deviations from the approved workflow.
e. The system shall enable users to benchmark contracts/orders against existing regulatory frameworks, e.g., quotas on Small Disadvantaged Business entities and
Set-Asides.
f. The system shall enable notification when changes to the Contracting Officer, Contract Specialist, COR, or Contractor Points of Contact changes occur.
g. The system shall enable email notification sent through EOP’s email system to the
COR, COR Supervisor, and Contractor for dissemination of COR Designation Letters.
h. The system shall enable email notification sent through EOP’s email system to the
COR and Contractor for dissemination of Government Shut Down Contingency
Planning letters.
i. The system shall enable mass email notification functionalities sent through EOP’s email system to COR and Contractor for dissemination of any EOP-wide policy related correspondence (i.e., COVID-19 guidance).
j. The system shall maintain a contract history log for auditing purposes.
5.4 Government Purchase Card (GPC) File Management
a. The system shall provide functionality for a GPC process to include steps for pre-approval of purchases and attaching the cardholder’s supporting documentation for all EOP components.
b. The system shall include the option of adding GPC data into contract reports for a comprehensive view of all EOP purchasing by component.
c. The system shall also provide functionality for logging convenience check transactions and 1099 reporting for all EOP components.
d. The system shall provide functionality for GPC order management, to include tracking request for purchase, products ordered, proof of delivery, and quantity of licenses where applicable.
5.5 Contract Search
a. The system shall store contracts in a format that supports both structured
(metadata) and unstructured (free-text) searching of documents, including all attachments, e.g., Boolean, proximity and exclusion.
b. The system shall provide the ability to assign metadata to documents.
c. The system shall provide the ability to conduct simple searches, as well as complex searches based on multiple user-selected criteria, e.g. date and component/tenant.
5.6 Analytics and Reporting
a. The system shall provide various metrics reporting and dashboards
Examples:
o list of active contracts/orders that can be organized by Component and contains desired contract/order portfolio details such as indicators for services, software, license, subscriptions, and hardware o scheduled reporting on a recurring basis for actions including upcoming actions within 30/60/90 days o number of actions and dollar values executed by person or by Component o COVID-19 clause incorporation o and ad hoc reporting such as Government Shutdown Contingency Planning
b. The system shall provide a set of canned reports that are common to contract lifecycle management, that can be filtered, organized, customizable by specifically identified data sets.
c. The system shall provide the ability to generate custom reports that would enable
EOP to track a multitude of metrics, such as:
o Workload reports.
o Financial Reports.
o Contracting Portfolio.
o Procurement Acquisition Lead Times.
d. The system shall provide the ability to subscribe to reports (canned or custom) that are automatically sent by email on a defined schedule.
e. The system shall also be able to track the following performance Metrics:
1. Efficiency: Performance metrics which include contract lifecycle time, contract specialist, contracting officer, customer, vendor, contract value assessments, and whether or not milestones were met.
2. Effectiveness: Performance metrics which include the number of contracts per type, contract specialist, contracting officer, COR, EOP component, and vendor.
Inclusive of contract value, the remaining value of expired contracts, order value variance, and historical legacy contract trends.
3. Risk: Performance metrics may include standard clause variance, amount of agreements expiring without renewal dates.
f. The system shall provide the ability to generate reports based on any contract field, such as the Contracting Officer Representative or the Requestor name.
g. The system shall enable users to benchmark contracts/orders against existing regulatory frameworks. (i.e., quotas on Small Disadvantaged Business entities and
Set-Asides)
h. The system shall measure cycle times for each workflow stage to reflect and compare actual processing times against benchmarks.
6.0 TECHNICAL REQUIREMENTS
6.1 Application Integration
a. The system shall fully support web service integration with internal systems and other cloud hosted applications.
b. It is highly desired that the system has pre-built Application Programming Interfaces
(APIs) for common federal acquisition system interfaces, such as the existing contract writing system, PRISM, managed by the U.S. Department of the Treasury’s, Bureau of the Public Debt, Administrative Resource Center (ARC).
c. The system shall support implementation of custom web API’s capable of transmitting XML or JSON formatted data using SOAP or REST-based protocols, at minimum.
https://www.cobblestonesoftware.com/resources/contract-software-lifecycle https://www.cobblestonesoftware.com/products/vendor-management-software https://www.cobblestonesoftware.com/contract-management-software/contract-analytics https://www.cobblestonesoftware.com/blog/4-critical-strategies-for-contract-value-generation https://www.cobblestonesoftware.com/blog/contract-termination-simple-three-step-approach
d. The system shall interface with financial management systems based in Oracle to track funding availability based on invoice disbursements and contract/order ceilings.
e. The system shall provide an electronic signature capability.
f. The system shall support Active Directory Federation Services (ADFS) for single sign-on.
g. The system shall integrate with business intelligence (BI) tools to preview, print, and export the system data for analysis purposes.
6.2 Role-based Access Control (RBAC)
a. The system shall provide pre-built user roles that are common to contract lifecycle management.
b. The system shall provide the ability to define and customize user roles and enable grouping of permissions.
c. The system shall enable the segregation of delete, edit, and add permissions.
d. The system shall provide an active user override to disable a user without removing them from the system.
e. The system shall be able to accommodate these distinct user roles (nomenclature may vary):
o Administrator: Assigns and manages user roles o CFO / Manager: Ability to manage and report on all content across the enterprise o Contracting Officer o Contracting Specialist o Contracting Officers Representative o Financial Manager / Funds Manager o Requisition Preparer o Requisition Approver o Budget Analyst o Government Purchase Card (GPC) Holder o GPC Coordinators o GPC Agency Program Coordinator APC) o GPC Approving Officials (AO) o Small Business Program Analyst o Procurement Analyst o Office of General Counsel (OGC)
6.3 Hosting
a. If the solution is cloud-based, the system shall be authorized FedRAMP Moderate.
b. Whether cloud-based or on-premise, the solution must be able to comply with the requirements of an Authority to Operation (ATO) granted through the Government’s
Security Approving Official/Authority. [Note: Vendors can demonstrate this ability by providing examples of prior ATO deployments in government settings.]
6.4 Data Management
a. The system shall be able to accommodate data handling under the PRA and FRA.
This informs how data must be processed for archive, as well as separation of data that must be archived vs. retained at the end of a Presidential administration. This requires the ability to perform a full data export (including all metadata and file attachments) at any time for data archive or backup purposes without removing the data from the system. The data export files should be available in .CSV, .XML formats.
b. The system shall be able to import/ingest from the export file formats.
c. The system shall be scalable and able to seamlessly handle increases in storage size as needed.
d. The system should be optimized, as data/files increase, for searching, retrieve and reporting tasks.
6.5 Security, Auditing, and Encryption
a. The system shall provide the ability for EOP to manage encryption keys.
b. The system shall encrypt data at rest and in transit.
c. The system shall provide auditing capabilities to capture system and user actions.
d. The system shall provide the ability to export audit logs for ingestion into external analytical platforms
e. The system shall provide a full system audit trail for contract records, with quick reporting capabilities on all audit history logs.
[End of Document]
File details come from the government source that posted it. Updated .