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
2
