SFS Bot - PDD v3.pdf

Process Design Document (PDD)

Criminal Justice Information Service

(CJIS)

BouncerBot

Document History

Date Version Role Name Office Function Comments

04/29/2020 05/04/2020

1.0, 2.0

Author James Newbrough

SCXP Business Analyst

Created document v 1.0, v 2.0

08/07/2020 3.0 Author James Newbrough

SCXP Business Analyst

Document Approval Flow

Version Flow Role Name Office Signature and Date:

Document prepared by

Business Analyst

James Newbrough

SCXP

Document Approved by:

Process Owner

Shawn SilvaCosgrove

SCOO

(CSC)

Document Approved by:

CoE Manager

Justin Daneill SCOK

Table of Contents

I. Introduction

I.1 Purpose of the Document

I.2 Objectives

I.3 Key Contacts

I.4 Minimum Prerequisites for Automation

II. As-Is Process Description

II.1 Process Overview

II.2 Applications Used in the Process

II.3 As-Is Process Map

II.4 Process Statistic

II.5 Detailed As-Is Process Steps

II.6 Input Data Description

III. To-Be Process Description

III.1 To-Be Detailed Process Map

III.2 Parallel Initiatives / Overlap (if applicable)

III.3 In Scope for RPA

III.4 Out of Scope for RPA

III.5 Business Exceptions Handling

III.6 Application Error and Exception Handling

III.7 Reporting

IV. Other Observations

V. Additional Sources of Process Documentation

I. Introduction

I.1 Purpose of the Document The Process Definition Document outlines the business process chosen for automation using UiPath

Robotic Process Automation (RPA) technology.

The document describes the sequence of steps performed as part of the business process, the conditions and rules of the process prior to automation and how they are envisioned to work after automating it, partly or entirely. This specifications document serves as a base for developers, providing them the details required for applying robotic automation to the selected business process.

I.2 Objectives The process that has been selected for RPA is the proof of concept selected by 66 ABG/SC for utilization and support of allied unit Security Forces (SFS). It is a quick win for Security Forces to automate processing of CJIS back ground checks and creating a time stamped data base of checks.

The business objectives and benefits expected by the Business Process Owner after automation of the selected business process are:

Automate CJIS processing to eliminate tedious manual data transfer

Reduce processing time per item by 50-75%

I.3 Key Contacts The specifications document includes concise and complete requirements of the business process and it is built based on the inputs provided by the process Subject Matter Expert (SME)/ Process Owner.

The Process Owner is expected to review it and provide signoff for accuracy and completion of the steps, context, impact and complete set of process exceptions. The names have to be included in the table below.

Role Name Contact details (email, phone number)

Notes

Process

SME

Adrianna Williams

Point of contact for questions related to process details & exceptions

Process Reviewer

Christine Tuatoo

Point of contact for questions related to process details & exceptions

Process Owner/ Approver for production

Martin Garland Escalations, Delays etc.

I.4 Minimum Prerequisites for Automation

1. Filled in Process Design Document

2. Test Data to support development

3. User access and user accounts creations (licenses, permissions, restrictions to create accounts for robots)

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

5. Dependencies with other projects on the same environment

II. As-Is Process Description

II.1 Process Overview General information about the process selected for RPA prior to automation.

# Item Description

1 Process full name Criminal Justice Information Service (CJIS)/BouncerBot

2 Process Area Visitors Center

3 Department Security Forces

4 Process short description (operation, activity, outcome)

Security Forces inserts key data from IDs, Passports and other forms of identification into CJIRs to retrieve personnel background information to authorize base access.

5 Role(s) required for performing the process

Security Forces Officer

6 Process schedule and frequency

Daily, Monday to Friday, 0800 - 1700

7 # of items processes /reference period

50-100/ day business as usual

8 Average handling time per item

10 minutes

9 Peak period (s) When events, ceremonies or otherwise coordinated events occur.

10 Transaction Volume During Peak period

30-50% volume increase

11 Total # of FTEs supporting this activity

2 Officers

12 Expected increase of volume in the next reference period unknown

13 Level of exception rate Determined when a degradation or outage of CJIS.

Varies by need of information required and IDs requiring check.

14 Input data ID, Passport or other identification method

15 Output data CJIS report; Excel Backlog of who has been run.

*Add more rows to the table to include relevant data for the automation process. No fields should be left empty.

Use “n/a” for the items that don`t apply to the selected business process.

II.2. Applications Used in the Process The table includes a comprehensive list all the applications that are used as part of the process automated, at various steps in the flow.

# Application name & version

System Language

Thin/Thick Client

Environment/ Access method

Comments

1 CJIS EN Thick Client

Web Browser

*Add more rows to the table to include the complete list of applications.

II.3 As-Is Process Map High Level As-Is Process Map:

This chapter depicts the As Is business process at a High Level to enable developers to have a high-level understanding of the current process.

Detailed As-Is Process Map:

Y N

II.4 Process statistics

High level statistics

Processes Windows Steps Mouse clicks

Keys pressed

Text entries

Hotkeys used

Time

1 1 11 12 40 5 0 180.0 sec.

Detailed statistics

Window name Mouse Clicks Text entries Keys pressed

Internet Explorer 12 5 40

II.5 Detailed As-Is Process Steps This chapter depicts the As-Is business process in detail to enable the Developer to build the automated process.

Detailed As-Is Process Steps

Step Input Description Details (Screen/ Document/ Video recording Index)

Exception Handling

Possible Actions

Business Rules Library Index

See doc attached

WI5_Process_Detail s.xlsx

II.6 Input Data Description Step Sample

(Print-screen)

Input type

Location Inputs are standard?

(Yes/ NO)

Inputs are structured?

Data to be used from

4 See WI5_ Detailed Process

Screen CJIS Data Box

YES YES State

12 See WI5_ Detailed Process

Screen CJIS Data Box

YES

YES

Name Date of Birth Sex Social Security Number

* Inputs are standard if the content is positioned in the same place even if the input types are different.

E.g. a process that uses at each transaction the same template, so fields to be extracted are always fixed..

Inputs are structured if it is machine readable and digital. Scanned PDF Images/ Free flow texts in Emails are unstructured inputs

III. To-Be Process Description This chapter highlights the expected design of the business process after automation.

III.1 To-Be Detailed Process Map

Highlight Bot interventions/ to-be automated steps with different legend/ icon (orange)

III.2 Parallel Initiatives/ Overlap (if applicable) This chapter captures the proposed Business, Process & System changes in near future and its impact

S. No Initiative Name

Process Step(s) where it is identified

Impact on current automation request?

How?

Expected Completion Date

Contact person for more details

2 Scanner Addition

Scan ID It’ll be the starting point where all the information is collected by the automation

As soon as possible.

Martin Garland

III.3 In Scope for RPA The activities in scope of RPA, are listed here:

1. Scan ID

2. Select Person

3. Enter State ID

4. Drivers License or Passport select

5. Leave BOP Note Default

6. Purpose Code set to criminal

7. Submit Data

8. Check info

9. Go to "All queries Tab"

10. Type III

11. Type in Personnal Data

12. Record Data Retrieved

III.4 Out of Scope for RPA The activities OUT of scope of RPA, are listed here:

Sub-process (if case)

Activity (step)

Reasons for Out of Scope*

Impact on the To-Be Possible measures to be taken into consideration for future automation

1.1 NA

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

III.5 Business Exceptions Handling The Business Process Owner and Business Analysts are expected to document below all the business exceptions identified in the automation process. These can be classified as:

Known Unknown

Previously encountered. A scenario is defined with clear actions and workarounds for each case.

Currently no automation process has been attempted for this on Hanscom AFB. Business exceptions will be identified as they come up.

Known Exceptions

The table below reflects all the business process exceptions captured during the process evaluation and documentation. These are known exceptions, met in practice before. For each of these exceptions, define a corresponding expected action that the robot should complete if it encounters the exception.

BE # Exception name

Step Parameters Action to be taken

1 Multiple persons with same name

9, 12 Name Input SSN to clarify correct person

Unknown Exceptions

For all the other unanticipated or unknown business (process) exceptions, the robot should:

Pop up an error box that notifies the user that something went wrong with the process and the automation stops mid process.

III.6 Application Error and Exception Handling

A comprehensive list of all errors, warnings or notifications should be consolidated here with the description and action to be taken, for each, by the Robot.

Errors identified in the automation process can be classified as:

Area Known Unknown

Technology/ Applications

Experienced previously, action plan or workaround available for it.

New situation never encountered before or may happened independent of the applications used in the process.

Know Errors or Exceptions

The table below reflects all the errors identifiable in the process evaluation and documentation.

For each of these errors or exceptions, define a corresponding expected action that the robot should complete if it is encountered.

# Error name Step Parameters Action to be taken

1 Application Crash / Internal Server Error

Any step Error message

Close the applications and run the sequence again

Unknown Errors and Exceptions

For all the other unanticipated or unknown application exceptions/errors, the robot should:

Pop up an error box that notifies the user that something went wrong with the process and the automation stops mid process.

III.7 Reporting

* For complex reporting requirements, include them into a separate document and attach it to the present documentation

IV. Other Observations

Include below any other relevant observations you consider needed to be documented here.

Example: Specific Business monitoring requirements (audit and reporting) etc.

V. 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

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

# Report type

Update frequency

Details Monitoring Tool to visualize the data

1 Excel After every ID run

TBD

Manual Review