RFP Attachment 1 - RPA BPA Statement of Work - 3.15.21.pdf

Federal Aviation Administration (FAA)

Strategic Sourcing for the Acquisition of Various Equipment and Supplies (SAVES) and Simplified Purchase Team (SPT)

AAQ-5B0

STATEMENT OF WORK

For

Robotic Process Automation

March 15, 2021

1. Introduction/Background

The FAA has a requirement for a Blanket Purchase Agreement (BPA) that will provide Robotic Process Automation (RPA) services to all FAA lines of business, staff offices, regions, and centers across the continental United States.

The contractor will work with FAA Business Units (clients) to develop and implement a Robotic Process Automation (RPA) solution. The solution will consist of “bots” that reduce or replace the need for employees to perform mundane, error-prone tasks such as copy-and-pasting data, analyzing large volumes of data and/or data aggregation. The “bots” will be either “Attended” requiring human intervention and/or “Unattended” without human intervention. The solutions will leverage industry leading, FEDRAMP compliant (or FAA Federal Cloud System (FCS) hosted), software (technology) approved by FAA Information Technology (AIT) and hosted in FCS.

2. Scope of Work

RPA services will be required nationwide, on an as-needed basis, in support of specific RPA requirements for all FAA Regional Offices. The BPA will include predetermined pricing for regions to utilize for acquisition procurement. Firm fixed price call orders will be issued under the respective BPA(s). The individual call orders will specify the services to be provided and not every BPA call will require every service listed in this Statement of Work.

Although process automation can vary by complexity, the table below should be used as a guideline to estimate the RPA cost per complexity level.

RPA Project Size and Time Frame Estimator Table

3. Requirements

The FAA has implemented a framework for robotic automation that consist of five phases:

1. Select the Process

2. Diagram the Process

3. Diagram the Automation

4. Select a Tool

5. Develop the Automation

This framework is based on industry-standard practice and is right-sized for RPA

Level # Bots # Applications/Systems Decision Est Timespan

Small 1 < 1 < 5 4‐6 weeks

Medium 2‐5 1‐2 5‐15 8‐12 weeks

Large > 5 > 3 > 15 > 12 weeks engagements; however, it is also general enough to enable innovative solutions. Each phase has specific goals, deliverables, and expectations. The following sections of this SOW specify which phases the FAA desires to solicit.

Process Selection Task The Contractor shall assist the FAA with evaluating the suitability of process(es) for robotic automation. The Contractor shall define an appropriate evaluation methodology that allows the FAA to determine good candidates for automation, included factors such as, but not limited to, complexity, stability, relative level-of-effort, and potential cost for automation.

The Contractor shall be required, at minimum, to describe the methodology and how it meets the evaluation goals. The Contractor may use some, all, or none of the FAA “RPA Candidate Evaluation Checklist” as part of the evaluation methodology. Access to the Checklist will be made available upon request to the Contracting Officer.

Diagram the Process Task The Contractor shall conduct requirements elicitation to gain a detailed understanding of the “as-is” process(es) that have been selected for automation. The Contractor shall consult any existing process documentation that may be available, as well as any policies or orders that apply to the process.

The Contractor shall model the as-is process using an industry-standard format. The Contractor must use Business Process Modeling Notation (BPMN), unless there is a specific and justifiable reason to use an alternative. The Contractor must get prior approval from the COR before adopting an alternative notation.

The Contractor shall ascertain and document, for each step in the process(es), the name, description, inputs and outputs, potential exceptions, and the data elements that are stored, copied, or referenced by each step.

The Contractor may use the FAA “Process Definition Document” (PDD) Template to meet the documentation requirements of this section, or use another preferred document. However, the chosen document must capture at least the same level of detail or more than the FAA’s Template. The template is available in the RPA Toolkit found at https://my.faa.gov.

Diagram the Automation Task The Contractor shall conduct requirements elicitation to gain a detailed understanding of the FAA’s desired “to-be” state of the entire or subset of process(es) it wishes to automate.

The Contractor shall model the “to-be” process using an industry-standard format. The Contractor shall use Business Process Modeling Notation (BPMN), unless there is a specific and justifiable reason to use an alternative. The Contractor must get prior approval from the

COR before adopting an alternative notation.

The Contractor shall ensure that steps to be automated are clearly delineated from those that will be excluded from automation, if any. The reasons for these exclusions and impacts of those exclusions must be documented.

The Contractor shall document known exceptions that may occur during the automation, along with the recommended steps for recovery.

The Contractor shall recommend metrics to the FAA to ensure any automation(s) are performing as expected and that will contribute to demonstrating the value of the automation over time.

The Contractor may use the FAA “Process Definition Document” (PDD) Template to meet the documentation requirements of this section, or another preferred document. However, the chosen document must capture at least the same level of detail or more than the FAA’s Template. The template is available in the RPA Toolkit found at https://my.faa.gov/go/rpa (FAA Network Only).

Select a Tool Task The Contractor shall consult with the FAA to select an RPA product that will meet the automation needs identified in the scope of this initiative. The Contractor shall define an appropriate evaluation methodology that allows the FAA to determine which product should be used; included factors such as, but not limited to, fitness, ease-of-use, and cost.

The products for consideration shall be limited to those previously approved by the FAA and included in the Technology Products List (TPL), which are Blue Prism, UiPath, and Pega Robotics (formerly OpenSpan).

The Contractor shall ensure that product selection is conducted in accordance with the FAA’s roadmap for implementation of specific product versions. Any deployment to an FAA-hosted environment will be subject to the version installed in that environment as of the planned deployment date.

Develop the Automation The Contractor shall deliver automation(s) that comply with the requirements approved by the FAA. The Contractor shall utilize an iterative development methodology that allows the FAA to examine the validity and accuracy of the requirements, and to respond to the usability and performance of introduced functionality, at regular intervals.

The Contractor shall be aware of and comply with the RPA governance policies and procedures established by the FAA, in addition to the relevant security and privacy policies.

Links to the relevant documents can be found in the RPA Toolkit found at https://my.faa.gov.

The Contractor is strongly encouraged to use an FAA-provided development environment.

However, the Contractor may use their own development environment with prior approval from the COR, if there is a compelling need to do so.

Regardless of the development environment, the Contractor shall ensure that any Releases are tested and deployed into the FAA-managed test and production environments. The Contractor shall, as early as feasible, advise the FAA of any potential license costs required to execute the automation(s), such as, but not limited to, developer tools, bot runtimes, or Virtual Machine (VM) usage.

The Contractor shall coordinate User Acceptance Testing (UAT) for each Release, and shall support FAA users during UAT. UAT must confirm that the automation is properly installed, configured, and remains in compliance with contractual and functional requirements.

The Contractor shall provide adequate training to ensure end users are adequately prepared to use the automation(s). This training may be in written form, delivered via screen-sharing, or other appropriate means. The Contractor shall ensure that the RPA Platform Administrator is aware of any specific administration requirements related to the delivered automation(s).

The Contractor shall ensure that any automation(s) delivered under this Task are registered in the FAA Bot Registry upon release to Production. In addition, the Contractor shall provide a briefing that specifies any specific runtime requirements or other relevant information necessary for production usage. The Contractor shall ensure the FAA has access to the un-compiled automation before release to Production.

4. Deliverables This section describes 1) the products and tangible end results that are expected from each task contained in the previous section, 2) the date each deliverable is due, and 3) the government acceptance criteria.

All days are business days unless otherwise specified.

Reference Deliverable Due Date Acceptance Criteria Evaluation Methodology TBD at Call

Level The Evaluation Methodology is complete and submitted on time in accordance with the criteria in the section “Process Selection

Task”.

Process Definition Document

(PDD)

TBD at Call Level

The PDD is accurate, complete, and submitted on time in the COR approved format.

Tool Selection Recommendation

TBD at Call Level

The Tool Selection Recommendation, including the evaluation methodology used, is complete and submitted on time in accordance with the criteria in the section “Select a Tool Task”.

RPA Developer Responsibilities

TBD at Call Level

A Signed “RPA Developer Responsibilities” document for every developer that will participate in this initiative.

Automation(s) TBD at Call Level

The Automation(s) are completed, demonstrated to conform with the requirements set forth by the FAA, and executing successfully in the approved FAA Production Environment, in accordance with section “Develop the Automation”.

End User training TBD at Call Level

Training developed and delivered in accordance with section “Develop the Automation”.

Bot Registration TBD at Call Level

The Automation(s) are registered in the designated FAA Registry and all information is accurate and complete.

Run-time Briefing TBD at Call Level

Designated FAA personnel are fully briefed on any run-time requirements.

Screen capture (video) of Automation(s) during execution (Attended automations only)

TBD at Call Level

A video file in the following format:

Video: .mp4 (H.264 encoding) Audio: .mp3

The resolution should be 640 x 360px. The file size should be 60mb or less, with a run time of less than 10 minutes. Less important sequences may be removed to reduce the run time.

System Owner Approval TBD at Call Level

Written approval (such as email) from System Owners for Systems the automation interacts with.

Privacy Threshold Assessment

(PTA)

TBD at Call Level

The PTA is based on the FAA-provided template, accurate, complete, and submitted on time in the COR-approved format.

Privacy Impact Assessment

(PIA)

TBD at Call Level

A PIA is required if determined by a PTA review. The PIA is based on the FAA-provided template, accurate, complete, and submitted on-time in the COR-approved format.

Security Checklist TBD at Call Level

The FAA-provided checklist is accurate, complete, and submitted on-time.

RPA Candidate Evaluation Checklist Version 5.0

Purpose: Use this form as a self-assessment to allow your Office to determine which candidates may be the best fit for Robotic Process Automation. You may use this information to prioritize or eliminate candidates, based on your needs.

Please note that this document is only a guideline. You may modify the scoring or questions to suit your particular situation, if you desire.

Use best practices when undertaking any initiative. A higher score on this evaluation does not guarantee success.

Process Evaluation

Process Name: Assessment Date:

Process Description:

Primary Contact Info (Name, Role):

SECTION I

a. How frequently is the process performed; for example, daily, weekly, etc.?

Daily or Weekly, score 3; otherwise, score 1

b. Does the process have a well-defined series of steps that are understood and executed by all participants?

For Yes, score 1; otherwise, score 0.

c. Is the process stable; meaning, no major changes are planned to the overall process in the immediate future, and no major changes are planned to any of the supporting applications that you are aware of?

For Yes, score 1; otherwise, score 0.

d. Are you aware of anything regarding this process that would impact potential automation, such as policy restrictions? For example, using a bot to access a financial system such as FPPS.

If there are no known negative impacts, score 1;

otherwise, score 0.

e. If some of the steps in the business process were automated (meaning they were executed automatically, without your intervention), do you believe that would reduce the amount of time required to complete the process or make the process more effective?

For Yes, score 1; for No, score 0.

Enter Score Here

SECTION I SCORE

If score 4 or more, continue to Section II. If score less than 4, proceed with caution as RPA may not be the right choice for your project.

SECTION II

f. How long has the current version of this process been operational?

For processes that have been operating in their current state for more than 6 months, score 1; otherwise, score 0.

g. Approximately how many employees participate in the process?

For 1 – 2, score 2; for 3 – 6, score 3; for more than 7, score 1.

h. Approximately how many decision points or approval steps are required in the process?

For Low (0-4), score 2; for Med (5-10), score 3; for High (11+), score 1.

i. Does the business process handle sensitive data or personally-identifiable information?

If this process does not handle any sensitive or PII data, score 1; otherwise, score 0.

j. Is there a business plan goal specifically related to this process?

k. Are there any measures/metrics that this process impacts?

If Yes, what are they?

l. Is there up-to-date and complete documentation for this process?

m. Are there frequent errors encountered when executing this process?

For Yes, score 1; for No, score 0.

n. Describe any manual steps in this process; for example, do you have to transpose data from either a printed document into an application, or between two applications?

Section I Subtotal

o. What applications do you interact with to execute this process? Please list all that apply.

SECTION II SCORE

SCORING

Lowest Score 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Highest Score

( ) Candidate For RPA Development (Score > 9) ( ) Not a good RPA Candidate

Comments:

Add Sections I & II Enter Total Here

C

Avoid Use Caution Explore Further

Section II Subtotal

Office of Information Technology Intelligent Automation Team

Process Definition Document {Project/Process Name}

Date: {Date}

About This Document This document describes the business process chosen for automation using

Robotic Process Automation (RPA) technology. This document should describe a single process.

The document describes the steps performed as part of the process, the conditions and rules of the process prior to automation, and how they should work after automation. This document will serve as the basis of a project to apply robotic automation to the selected process.

Minimum Prerequisites for a Successful Automation

1. Completed Process Definition Document

2. Credentials (user ID and password) required to logon to machines and applications

3. Test Data to support development.

About the Selected Process The process selected for automation is called {Process Name}. {Describe the process briefly, including the users of the process and what the process is meant to accomplish. You should also describe any particular issues with the process, if any}.

The business objectives and benefits expected after automation of the selected business process are:

{List the specific expectations}

Points‐of‐Contact Role Name Email Notes Process SME Point of contact for questions related to process details and exceptions

Process Owner Manages and oversees the objectives and performance of the selected process

Business Analyst Assists with understanding and documenting the process

{Add any additional roles that make sense}

Process Overview

ITEM DESCRIPTION

Process Name

Owning Organization

Process Short Description

Roles Defined In Process

Process Schedule/Frequency

Average Process Execution Time

Peak Period(S) For Process Execution

Number Of FTEs Involved With Process

Average Number Of Exceptions Per Process Execution

Process Inputs

Process Outputs

Dependencies

Systems/Applications Used in the Process System/Application Name

Access Method (Browser/Windows App/etc.)

Comments

{Don’t forget to include desktop applications like Microsoft Outlook or Word, if applicable.}

As‐Is Process Diagram {Include a diagram that shows the process as it currently exists. You can use Microsoft Word, Visio, PowerPoint, or any other tool that allows process diagramming, but the process model should be copied‐and‐pasted into this document.

It is highly recommended that Business Process Modeling Notation (BPMN) be used to diagram the process.

However, even a traditional flow chart is better than nothing. Here is a link to the BPMN standard:

https://www.process.st/bpmn‐tutorial/ (Note: this site is maintained by a third party).}

As‐Is Step Details Name Description Input(s) Output(s) Exception

Handling Procedures

{For each step in the process diagram above, describe the details. Add additional rows as needed. If this information already exists, just attach it to this document.

No need to duplicate it here, but it should include the information above, at a minimum.}

Input Data Associated Activity Input Method (Screen, PDF

Form, etc.)

Data Elements

{For each activity in the process diagram above, describe the data required. Add additional rows as needed. If this information already exists, just attach it to this document. No need to duplicate it here, but it should include the information above, at a minimum.}

To‐Be Process Diagram {Use this page to include a diagram that shows the design of the process after automation. Use a distinguishing property (like color, for example), to indicate the steps that will be automated.}

Planned Process Changes Change Description

Process Step(s) Impacted

Expected Impact

Planned Completion Date

Point‐of‐ Contact

{Ideally, the process to be automated will have no planned changes on the horizon. However, if there are any planned changes (including improvements that are undertaken because of the application of Intelligent Automation, list them here.}

Out of Scope Activity or Step Reason for Exclusion

{Identify the process steps that are not going to be automated, and indicate why.}

Exceptions The “As‐Is Step Details” section describes how errors are handled in the As‐Is

Process. Use this section to describe the specific actions the automation should take when errors are encountered.

Exceptions are roughly divided into two types: Known (encountered before) and

Unknown (unexpected, and therefore unplanned for).

Unknown exceptions are unrecoverable and should cause a notification and stop further process execution. The notification approach is listed below, along with further information on how to handle Known exceptions.

Unknown Exceptions

Exception information will be sent via email to {recipient(s)}, along with any log information that is available.

Known Exceptions

Exception Description Related Step (if applicable)

Action(s) to be Taken if Encountered

Metrics/Reporting Automation should be monitored, both to ensure it is performing as expected, as well as to demonstrate the value of the automation over time.

{The table below contains examples, but these should be replaced with your specific needs.}

Data Collection Type

Update Frequency

Purpose

Process logs Daily How many times was this process run since the beginning of the month and what was the average run duration?

Process logs Monthly How many robots worked on this process per each month?

Transaction logs Daily How many transactions were run by this process since the beginning of the month and what was the average transaction duration?

Error logs Daily Average number of errors by type per day

Error logs Daily All errors per month grouped by type

Additional sources of process documentation

If there is additional material created to support the process automation please mention it here, along with the supported documentation provided.

Additional Process Documentation

Video Recording of the process Insert link to the video recording and provide access to the video.

Date and time of the recording.

Insert additional relevant comments

List of supporting documents Embed documents List here all the templates, mapping tables, list of URLS that are provided as supporting info for automation.

Standard Operating Procedure (s)

(Optional)

Insert link to the standard operating procedure related to the process in scope.

Insert any relevant comments

Other documentation

(Optional)

Insert link to any other relevant process documentation (L4, L5 process description, fields mapping files etc)

Insert any relevant comments

*Add more table rows to reflect the complete documentation provided to support the RPA process.

Other Important Information <Insert any relevant information deemed worthy of inclusion.>