Contenu connexe

Similaire à Steps towards RPA Development: How to Document your Automation.pdf(20)

Plus de Cristina Vidu(20)


Steps towards RPA Development: How to Document your Automation.pdf

  1. Steps towards RPA development: How to document your automation
  2. 2 RPA Tech Lead RPA PM Stefano Negro Enrico Bruno Hosts
  3. 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. 4 Introduction
  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
  7. 7 Process Definition Document - II
  8. 8 Process Definition Document - III Missing Logic Cannot be automated Undocumented Applications
  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
  15. 15 Examples - Documents • Process Assessment • PDD • SDD • DPD • Test
  16. 16 Examples - Flows
  17. 17 • - Solution Architect Fundamentals • Resources