Steps towards RPA development:
How to document your automation

2
RPA Tech Lead
s.negro@bspconsultant.it
https://www.linkedin.com/in/stefanonegro/
RPA PM
e.bruno@bspconsultant.it
https://www.linkedin.com/in/enricobruno/
Stefano Negro Enrico Bruno
Hosts
https://community.uipath.com/torino/

3
1. Introduction
2. Before the Documentation
3. Process Definition Document
4. Solution Design Document
5. Other Docs
6. Tips and Tricks
7. Examples
8. Q/A
Agenda

4
Introduction

5
Before the Documentation
• Best Practice Agreement
• Coding standards
• Versioning (documentation and development)
• Development effort estimation

6
As-Is
• Business aspects of
the process
• Current workflow
• Expected Input and
output
To-Be
• High level solution
• Current workflow
integrated with
technical changes
• Expected Input and
output + Reporting
and logs
Sign-Off and Extra-Requirements
• Sign-Off is necessary
to start development
• Every changes
related to the process
need estimation
Process Definition Document
Done by Business
Analyst
Done by Business
Analyst and Solution
Architect
Done by Solution
Architect and Process
Owner

7
Process Definition Document - II

8
Process Definition Document - III
Missing Logic Cannot be automated
Undocumented
Applications

9
• Created before development at Design phase
• Can be a standalone document or integrated within PDD
• More technical aspects compared with PDD
• Consider Development aspects:
-Components reusability
-Queues/ ReFramework/ Dispatcher-Performer
-Assets and their Governance
• Discuss major business aspects with PM, Analyst and Process Owner
Solution Design Document

10
• Created during development
• Contains every major aspect related to development
• Custom Activities/ Codes
• Templates, Queues, Configuration files
• Constant and credential naming and storage
• To be updated in case of Changes/Fixes during Live Phase
• Sometimes can contain also relevant monitoring data (eg. Average run time,
major errors encountered)
• Signed off by Solution Architect
Development Specification Document

11
• Compiled after development, during test phase
• Should contain all possible scenarios, both correct and incorrect
• Tests have to be related to the PDD flow, and all the END branches have to be
present.
• Signed off by Process Owner as User Acceptance Test
Test Scenario Document

12
• Not mandatory but useful to select process at the start of the project
• Some rules are objective, while others are judgmental
• Event error predictability
• Time effort
• Can be changed based on needs of the project and the company
• Size
• RPA CoE availability
Process Assessment Matrix

13
• Maintain a centralized repository
• For documentation (eg. Sharepoint) as well as development (eg. GIT)
• Define naming convention from the start
-Decide on Process naming, assets, queues, templates, credentials
• Use a fixed matrix for Effort Estimation
-Number of sub-processes
-Number of applications used
-Number of steps
-Logic complexity (if, loop, switch)
Tips and Tricks

14
• Reusability is for development, but also for analysis
-Try to provide similar logic to similar processes
-Standardize reporting and logging
• The PDD is useful for what has to be automated, but also for what is out of
scope (or handled manually)
• The three most important things: reporting, reporting and reporting
• T-A-S-K C-A-P-T-U-R-E
Tips and Tricks - II

15
Examples - Documents
• Process Assessment
• PDD
• SDD
• DPD
• Test

16
Examples - Flows

17
• https://academy.uipath.com/ - Solution Architect Fundamentals
• https://community.uipath.com/Torino
Resources