Query Ticket Creation Process
Process Definition Document (PDD)
Document History
Date
Version
Role
Name
Organization
Function
Comments-
Author
ADITYA DESINEEDI
COE
Business Analyst
Created document v 1.0
Contents
1.Introduction4
1.1Purpose of the document4
1.2Objectives4
1.3Process key contacts4
1.4Minimum Pre-requisites for automation5
2.As IS process description5
2.1Process Overview5
2.2Applications used in the process5
2.3As IS Detailed Process map6
2.4Additional sources of process documentation7
3.To BE Process Description8
3.1TO BE Detailed Process Map8
3.1.1Change/Improvement details8
3.1.2Areas already automated9
3.2In Scope for RPA9
3.3Out of Scope for RPA9
3.4Business Exceptions Handling9
3.4.1Known Exceptions9
3.4.2Unknown Exceptions10
3.5Application Error and Exception Handling10
3.5.1Know Errors or Exceptions11
3.5.2Unknow Errors and Exceptions11
4.Other Requirements and Observations12
5.Document Approval12
1. Introduction
1.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.
1.2 Objectives
The business objectives and benefits expected by the Business Process Owner after automation of the selected business process are:
Reduce processing time per item by 80 %.
Minimizes the errors while entering data to ServiceNow.
1.3 Process 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
ADITYA DESINEEDI-Mobile:-
Point of contact for questions related to business exceptions and passwords
Process Reviewer /
ADITYA DESINEEDI-Mobile:-
Point of Contact for process exceptions
Process Owner/ Approver for production
ADITYA DESINEEDI-Mobile:-
Escalations, Delays,
1.4 Minimum Pre-requisites for automation
1. Filled in Process Definition Document
2. Credentials (user ID and password) required to logon to machines and applications
3. Test Data to support development.
2. As IS process description
2.1 Process Overview
General information about the process selected for RPA prior to automation.
#
Item
Description
1
Process full name
Query Ticket Creation Process
2
Process Area
Customer Service
3
Department
Finance and Accounting
4
Process short description
(Operation, activity, outcome)
Reads data from excel and create a ticket for each customer query in ServiceNow.
5
Role(s) required for performing the process
ServiceNow user
6
Process schedule and frequency
Daily, Monday to Friday, 9 am – 6 pm
7
# of items processes /month
~4500
8
Average handling time per item
4 min
9
Peak period (s)
End of month, usually from 20th to 28th day of each month
10
Total # of FTEs supporting this activity
5
11
Level of exception rate
~20% exceptions (Incorrect data is entered to ServiceNow etc.)
12
Input data
Excel in a shared folder
13
Output data
Creating a Query Ticket in ServiceNow
14
Dependencies
(Upstream, downstream)
n/a
2.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
Login Module
Interface
Environment/
Access method
Comments
(Include URLs)
1
Excel
EN
n/a
Client
Local desktop
Single Sign On
2
ServiceNow
EN
n/a
Client
Local desktop
Test user in ServiceNow identical with production system.
2.3 As IS Detailed Process map
This chapter depicts the AS IS business process in detail to enable the developer to build the automated process.
{Detailed process map to be added here, with input/output flow at each stage. Divide the process into stages if required (for better readability)}.
Add the AVG TAT (Average Turn Around Time) for each key transaction/ activity. Use the “Short description of key process steps” . More detailed information can be documented in a separate table and/or documented and embedded in this document/ Section.
Example:
{Fill in the table below with a short description of the process steps presented in the AS IS diagram}.
Step
Short Description of Key Process Steps
AVG
TAT*
1
Check the input excel file exists that needs to be processed
2
If the input file is missing
3
Send the mail to business team
4
Stop the bot processing
5
Else follow from step 5
6
Logon to ServiceNow
7
Search for incidents in ServiceNow
8
Create ticket for each user in ServiceNow
9
Repeat the Step 8 for all the users in input file
10
After the input file is processed, send an email notification that the action is complete
11
Move the file to the “Processed” folder
12
Stop the bot processing
In the AVG TAT (Average Turn Around Time) please fill in the current TAT of each transaction. More detailed information can be documented in a separate table and/or documented and embedded below.
2.4 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 [Mandatory]
Insert link to the video recording and provide access to the video.
08/03/2022
List of supporting documents
D:\Users\Aditya\Documents\UiPath\QueryTicketProcessing\Data\Input\UserDetails.xlsx
This is the format of input excel file
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.
3. To BE Process Description
This chapter highlights the expected design of the business process after automation.
3.1 TO BE Detailed Process Map
{Detailed process map to be added here, with input/output flow at each stage. Divide the process into stages if required (for better readability)}.
Example:
3.1.1 Change/Improvement details
Use this section to detail the list the change or improvement opportunity in the To-Be Process.
Important aspects to be mentioned: what is the initiative, expected outcome, expected completion date, contact person for details, and if will impact the current automation request.
#
Initiative name and Expected Outcome/Benefits
Process Step(s) where it is identified
Does it impact the current automation request? How?
Expected completion date
Contact person for more details
1.
2.
3.
3.1.2 Areas already automated
List the areas and branches where the process is already automated. Mention if that has any impact on the current automation request.
3.2 In Scope for RPA
The activities in scope of RPA, are listed here:
Example:
1. Verify input file in shared folder
2. Handle exception if file is missing
3. Post data in ServiceNow
4. Send confirmation email
3.3 Out of Scope for RPA
The activities OUT of scope of RPA, are listed here. Mention of the changes/ improvement opportunities identified for automation are out of scope for this automation iteration.
Example:
1. Bulk creating of tickets in ServiceNow
3.4 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.
New situation never encountered before. It can be caused by external factors. Cannot be predicted with precision, however if it occurs, it must be communicated to an authorized person for evaluation.
3.4.1 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
Missing input file
Step # 2
If file is missing
send email by using Reply email function
“Hello,
The shared folder is missing the input file. Please verify the input file is generated.
Thank you”
2
ServiceNow Login Failed
Step # 6
Login error
send email for additional details: Reply email
“Hello,
An unknown error happened while trying to login to ServiceNow.
Thank you”
3
Tickets Created Successfully
Step # 10
Tickets Created
Send email to-
“Hello,
Processed completed successfully, and the ticket is created for each user.
Thank you,”
Insert more table rows if necessary to capture all the exceptions in a comprehensive list.
3.4.2 Unknown Exceptions
For all the other unanticipated or unknown business (process) exceptions, the robot should:
{Define a corresponding expected action that the robot should complete if it encounters unknown exception.}
Example:
send an email notification at-[insert full name, function and email address] with the original email and error message screenshot attached.
3.5 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.
3.5.1 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.
AE #
Error name
Step
Parameters
Action to be taken
1
Access to shared folder
Step #2
Error message
Mail to the business team
2
ServiceNow login failed
Step 6
Account deactivated
Send email with screenshot to RPA supervisor.
Insert more table rows if necessary to capture all the exceptions in a comprehensive list.
3.5.2 Unknow Errors and Exceptions
For all the other unanticipated or unknown application exceptions/errors, the robot should:
{Define a corresponding expected action that the robot should complete if it encounters an error or unknown exception.}
Example:
send an email notification at-[insert full name, function and email address] with the original email and error message screenshot attached.
4. Other Requirements and Observations
Include below any other relevant observations you consider needed to be documented here.
Example: Specific Business monitoring requirements (audit and reporting) etc.
5. Document Approval
This document requires serial approval (sign off) from the roles defined in the table below.
Changes to the requirements must be documented in an updated version (i.e v 2.0) and requires a new signature flow.
Version
Flow
Role
Name
Organization
(Dept.)
Approval Date:
1.0
Document prepared by
Technical Solution Architect
ADITYA DESINEEDI
RPA Learners
08/03/2022
1.0
Document Approved by:
Process Owner
Client Name
Client Organization
1.0
Document Approved by:
Operations
Name Surname
1.0
Document Approved by:
Compliance
Name Surname
1.0
Document Approved by:
RPA Architect/ Developer
Name Surname