In this community event we will see what are the basic concepts regarding Documentation, how to document an automation following best practices and some tips & tricks to increase the Analysis phase of your automation journey.
📕 Some of the topics that will be discussed are:
Before Documentation: what to define at the start of an automation journey in order to avoid mistakes and challenges that can appear later
How to create Automation Documents and what best-practices to follow
Highlights on Process Definition Document, Solution Design Document and other docs
Tips and tricks
Examples of good (and bad) documentation!
👨💻 Speakers:
Stefano Negro, UiPath MVP, RPA Tech Lead @BSP Consultant
Enrico Bruno, Project Manager @BSP Consultant
5. 5
Before the Documentation
• Best Practice Agreement
• Coding standards
• Versioning (documentation and development)
• Development effort estimation
6. 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
9. 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. 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. 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. 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. 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. 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
