s

Process
Definition
Document
{Title}

{Description}

2
TABLE OF CONTENTS
I. INTRODUCTION..................................................................................................................................................................4

1.1 Purpose...........................................................................................................................................................................4

1.2 Objectives........................................................................................................................................................................4

1.3 Key Contacts...................................................................................................................................................................4

1.4 Minimum Pre-requisites for the Automation............................................................................................................4

II. AS IS Process description................................................................................................................................................5

2.1 Process Overview...........................................................................................................................................................5

2.2 Applications Used..........................................................................................................................................................6

2.3 AS IS Process Map.........................................................................................................................................................7

2.3.1 High Level Process Map................................................................................................................................7

2.3.2 Detailed Level Process Map.........................................................................................................................7

2.4 Process Statistics............................................................................................................................................................7

2.5 Detailed As Is Process Actions......................................................................................................................................8

2.6 Input Data Description.................................................................................................................................................8

III. TO BE Process description..............................................................................................................................................9

3.1. Detailed TO BE Process Map.................................................................................................................................9

3.2. Parallel Initiatives....................................................................................................................................................9

3.3. In Scope For RPA.....................................................................................................................................................9

3.4. Out Of Scope for RPA...........................................................................................................................................10

3.5. Exceptions Handling.............................................................................................................................................10

3.5.1. Known Business Exceptions......................................................................................................................10

3.5.2 Unknown Business Exceptions..............................................................................................................10

3.6. Applications Errors & Exceptions Handling.....................................................................................................11

3
 3.6.1. Known Applications Errors and Exceptions..........................................................................................11

3.6.2. Unknown Applications Errors and Exceptions.....................................................................................11

3.7. Reporting................................................................................................................................................................11

IV. Other...................................................................................................................................................................................12

4.1. Additional sources of process documentation................................................................................................12

I. INTRODUCTION

0
1
1.1 Purpose
The Process Definition Document outlines the business process chosen for automation. The
document describes the sequence of actions performed as part of the business process, the
conditions and rules of the process prior to automation (AS IS) as well as the new sequence of
actions that the process will follow as a result of preparation for automation (TO BE).

The PDD is a communication document between:

 The RPA Business Analyst and the SME/Process Owner. The goal is to ensure that the
RPA Business Analyst has the correct understanding of the process and has represented
it accurately.
 The RPA Business Analyst and the Development team (represented by the Solution
Architect and RPA Development Lead). The goal is to ensure that the process is
documented appropriately and to a sufficient level of detail so that the Solution Architect
can then create the solution based on the PDD content.

4
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%.

 Better Monitoring of the overall activity by using the logs provided by the

robots.

1.3 Key Contacts

Add here any stakeholders that need to be informed or to approve changes to the process:

Role Name Contact Details Notes

(email, phone
number)
{Author}

1.4 Minimum Pre-requisites for the Automation

a) Filled in Process Definition Document
b) Test Data to support development
c) User access and user accounts creations (licenses, permissions, restrictions to create
accounts for robots)
d) Credentials (user ID and password) required to logon to machines and applications

II. AS IS PROCESS
DESCRIPTION
In this section the Business Analyst will document the process. This section will serve as the
starting point for the re-engineering and automation effort.

5
2
2.1 Process Overview
Section contains general information about the process before automation.

Item Description/Answer

Process Full Name {Title}

Process Area

Department

Short Description (operation, activity, {Description}

outcome)

Role(s) required in applications to perform

the process

Process schedule and frequency

Number of times the process is ran by

selected frequency

Process execution time {process_execution_time}

Process Restrictions e.g. This is necessary for the Solution Architect to

decide how they will need to split the Master Project
into smaller projects (the scheduling of the robots
will depend on this)

Example: The applications can be used only

between 7 AM-8PM during work days and not
allowed to be used during weekend.

Peak Period (s) e.g. It is important to understand peaks in order to

design a robust and scalable  solution.

Example:   Beginning of month, usually from 28th to

30th day of each month

Peak Volume Approximate increase E.g. It is important to understand peaks in order to

design a robust and scalable solution.

Example: 600

6
 Number of persons performing the process

Expected Volume increase during next e.g. It is important to understand peaks in order to
periods design a robust and scalable solution.

Example: 10-20%

Percentage Un-handled exceptions

Input data description e.g.: pdf invoices from ~100 suppliers

Output Data description e.g. posted invoices report in SAP

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

2.2 Applications Used

The table includes a comprehensive list of all the applications that are used as part of the process
to be automated to perform the given actions in the flow.

Environmen
Application Application Thin/Think
Version t/ Access Comments
Name Language Client
method

[This is important Application

for the RPA Language
Developers as: [This is important
It is not as different
uncommon for application
development languages can
environments to also mean
have lower different settings
versions compared (e.g. dot versus
to the production comma as decimal
one; separator). If the
The developer will developer is aware
know (or will know of the language
they have to then they will
investigate) if they know what are the
can re-use a challenges that
component that come with that.]
exists for a
previous version
or if they need to
develop a new
one]

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

2.3 AS IS Process Map

This section contains various process maps contributing to a better understanding of how the
process is performed pre-automation.

2.3.1 High Level Process Map

This section is useful for the Business Analyst in presentations and discussions with management
to underline areas of weakness, inefficiency or to demonstrate which actions could be in scope
for automation.

{%diagram}

2.3.2 Detailed Level Process Map

This section describes the process at key-stroke level and is an essential part for the
communication with the developers.

2.4 Process Statistics

High Level statistics

Mous Hotkey Time

Keys Text
Processes Windows Actions e s used
pressed entries
clicks

{total_applicat {total_windo {total_actio {total_ {total_keys {total_text {total_h {process_exec

ions_count} ws_count} ns_count} clicks} _pressed} _entries} otkeys} ution_time}

Detailed statistics

8
 Window name Mouse clicks Text entries Key pressed

{total_keys_pressed}
{#windows}{name} {total_clicks} {total_text_entries}
{/windows}

2.5 Detailed As Is Process Actions

Details
(Screen/Video Exceptions
#Action Input Description Possible Actions
Recording Handling
Index)

{#sequenceLayout}

1. {sequenceTitle}

{sequenceDescription} Est. time:

{sequence_execution_time}

{#actionLayout}

1.1 {actionTitle}

{actionDescription} Est. time: {action_execution_time}

{%actionImage}
{#action_metadata}

Action: {action_type}

{/action_metadata}

{/actionLayout}

{/sequenceLayout}

9
2.6 Input Data Description
The following table should contain details regarding the inputs that every action of the process
takes.

Are inputs
Are the Inputs
#Action Sample Input Type Location Natively
Structured*?
Digital*?

* Native Digital: This is data that was originally created digitally e.g. excel, database or application reports etc. The
non-native digital inputs are usually scanned images.

* Structured Data: has a predictable format and exists in fixed fields (e.g. an excel cell or a field in a form) and is
easily detectable via search algorithms.

10
III.TO BE PROCESS
DESCRIPTION

In this section the proposed improvements to the process, actions to the process will be outlined
as well as the actions proposed for automation and the type of robot required. This will be
cross-checked by the Solution Architect.

III.1. Detailed TO BE Process Map

A detailed process map of the process as it will look like post-automation will be outlined here.

Highlight Bot interventions/ To-Be automated actions with different legend/ icon (purple).
Mention below if process improvements were performed on the To-Be design and provide details.

Legend Description

Action number in the process. Referred to in details or Exceptions and Errors table.

This process action is proposed for automation.

This process action remains manual (to be performed by a human agent).

III.2. Parallel Initiatives

The table below will capture the proposed Business, Process or Application changes to be made
in the near future that would impact the process at hand (if any).

Process Impact on current

Expected
Initiative Name Action(s) where Automation Contact Person
Completion Date
it is identified Request

11
III.3. In Scope For RPA
The actions in scope for RPA should be listed below:

III.4. Out Of Scope for RPA

The actions out of scope for RPA should be listed in the table below together with the reasoning.

Possible measures to
be taken into
Reason for out of
Activity/Action* Impact on the TO BE consideration for
scope
future automation

e.g. Action 3 e.g. Input is handwritten e.g. after action 2 an e- e.g. collect the input in pdf
mail is sent to the user form and use electronic
to manually perform signature
action 3

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

III.5. Exceptions Handling

The Business Process Owner and Business Analysts are expected to document below all the
business exceptions identified in the automation process. Exceptions are of 2 types and both
need to be addressed:

Known exceptions = previously encountered. A scenario is defined with clear actions and
workarounds for each case.

Unknown = New situation that was not encountered before. It cannot be predicted and in case
it happens it needs to be flagged and communicated to an authorized person for evaluation.

III.5.1. Known Business Exceptions

Details regarding how the robot should handle the exceptions.

Action to be taken
Exception Name Action Parameters

e.g. Employee ID <> 6 e.g. Action 1 e.g. Employee ID e.g. send an e-mail to

12
 characters [email protected]
with the text: “Employee ID <>
6 characters”
Go to the next transaction

3.5.2 Unknown Business Exceptions

An umbrella rule that includes a notification needs to be designed for all other exceptions that
could happen and cannot be anticipated.

e.g.: for all other cases which do not follow the rules defined an e-mail should be sent to:
[email protected] with a screen shot and robot should proceed to next transaction.

III.6. Applications Errors & Exceptions Handling

A comprehensive list of all errors, warnings or notifications should be consolidated here together
with the action to be taken for each by the Robot. There are 2 types of exceptions/errors:

Known = Previously encountered and action plan or workaround available for it (e.g. SAP
unresponsive during peak times)

Unknown = these are exceptions and errors that cannot be anticipated but for which the robot
needs to have a rule so that the RPA solution is sustainable.

III.6.1. Known Applications Errors and Exceptions

Details regarding how the robot should handle the exceptions.

Action to be taken
Error/Exception Name Action Parameters

e.g. Application Crash e.g. Any action e.g. Error message e.g. recover and retry 3
times

III.6.2. Unknown Applications Errors and Exceptions

An umbrella rule that includes a notification needs to be designed for all other exceptions that
could happen and cannot be anticipated.

e.g. robot should attempt to access the application 3 times then it should terminate thread.

13
III.7. Reporting
In this section all the reporting requirements of the business should be detailed so that when the
RPA solution is moved to production the administrators can track the performance of the
solution.

Monitoring Tool to
Report Type Update frequency Details visualize the data

e.g. Process logs e.g. Daily e.g. How many times e.g. Kibana
was this process run
since the beginning of
the month and what was
the average run
duration

e.g Process logs e.g. Monthly e.g. Csv file posted daily
e.g. How many robots
on share drive
worked on this process
per each month?

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

e.g Error logs e.g. Daily e.g. Average number of e.g. Kibana
errors by type per day

e.g Error logs e.g. Daily e.g. All errors per month e.g. Csv file posted daily
grouped by type on share drive

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

IV.OTHER
IV.1. 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.

14
 Additional Process Documentation

Video Recording of the Acme-System1-Process-WI5- Insert any relevant comments

process (Optional) Manual-Walkthrough

Business Rules Library Insert link to Business rules Insert any relevant comments
(Optional) library

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

Standard Operating Insert any relevant comments

Procedure(s) (Optional)

High Level Process Map Insert any relevant comments

(Optional)

Detailed level process map Insert any relevant comments

(Optional)

Work Instructions Insert any relevant comments

(Optional)

Input Files (Optional) Insert any relevant comments

Output Files (Optional) Insert any relevant comments

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

15