A Day in the Life of an RPA Developer
Overview
The module is for beginners and takes 40 mins to complete. Its primary purpose is to teach the differences between processes and procedures, provides you with the set criteria for assessing automation potential, and describes the responsibility and collaboration of the RPA Developer throughout the stages of an RPA project implementation.
What you will learn in this course
- Explain what a process is and differentiate it from a procedure.
- Use the set criteria to evaluate if a process is fit for automation.
- Describe the stages of an RPA project implementation.
- Discuss the tasks and ownership of the RPA Developer at each stage of implementation.
- Describe the collaboration with other roles throughout the stages of an RPA project implementation.
Important take outs
As an RPA Developer, your main focus is the automation of processes. So what is a business process? A process is a set of interrelated or interacting activities that transforms inputs into outputs.
Components of a process:
- Inputs – the data that goes in the process.
- Process Flows – the sequences of sub-processes or activities undertaken in the process.
- Source Applications – the applications or systems used to perform the sub-processes or activities of the process.
- Outputs – the result generated by the process.
Organizations use processes because planning and executing them under controlled conditions can, among other things, improve compliance, ensure that operational needs are met, help in managing risks, and drive improvement.
The relation between processes and procedures
A procedure complements a process and describes the way it’s carried out; it explains who’s responsible for each part of the process, when each part of the process needs to occur, how to handle exceptions, and the specifications applicable to each part of the process.
A procedure explains:
- Who’s responsible for each part of the process.
- When each part of the process needs to occur.
- How to handle exceptions.
- The applicable specifications to each part of the process.
A process is typically documented via a diagram, be it a flowchart or workflow, which aims to highlight the logical sequence of the process steps. A procedure, on the other hand, is often a complex, written document, focused on providing guidelines.
What makes a process a good candidate for automation?
The two sets of criteria you can use to determine the automation potential are process fitness and automation complexity.
Process Fitness
Rule-based: The decisions made (including data interpretation) in the process can be captured in a pre-defined logic. The exception rate is either low or can be included as well in the business logic.
Repetitive process: We can differentiate four types of processes:
- Manual and non-repetitive: the process steps are performed by humans and can be different every time the process is executed.
- Manual and repetitive: the steps in the process are performed by the user, and at least some of them are the same every time.
- Semi-automated and repetitive: some of the repetitive steps have already been automated (using macros, Outlook rules, and so on).
- Automated: there are processes that have already been automated using other technologies than RPA.
Processes that need to stay manual or are non-repetitive, due to the high exception rate or factors that cannot be integrated into business logic, aren’t good candidates for automation.
Standard input: The input in the process should either be electronic and easily readable or readable using a technology that can be associated with RPA (such as OCR). A good example is an invoice having the fields pre-defined.
Stable: Processes that have been the same for a certain period of time and no changes are expected within the next few months are good candidates for automation, provided they meet the other criteria as well.
Automation complexity
The following criteria determine how hard it is to automate a process.
The number of screens: RPA works by programming the robot to perform tasks at screen level (when the screen changes, the logic has to be taught). The higher the number of screens, the more elements have to be captured and configured before process automation.
Types of applications: Some applications are more easily automated (such as the Office suite or browsers), others heavily increase the automation effort (Mainframe, for example). And the more different applications there are, the number of screens will increase, as well (see the previous point).
Business logic scenarios: An automation’s complexity increases with the number of decision points in the business logic. Basically, each one could multiply by two times the number of scenarios.
Types and number of inputs: As previously stated, standard input is desirable. Yet there are cases in which one standard input (such as an invoice) has to be configured for each supplier that will be affected by the automation. Moreover, non-standard input can be of different complexity grades, with free text being the most complex.
Assessing the automation potential
By using these factors in our automation potential assessment, we can sort processes into four categories:
- No RPA: Processes where change is frequent, the system environment is volatile, and multiple manual (even non-digital) actions are required.
- Semi-Automation: Processes that can be broken down into steps that can be clearly automated, and steps that need to stay manual (such as validations or usage of physical security tokens).
- High-Cost RPA: Processes that are rather digital and can be automated, but use some technologies that are complex (such as OCR) or require advanced programming skills.
- Zero-Touch Automation: Processes that are digital and involve a highly static system and process environment, so that they can be easily broken into instructions and simple triggers can be defined.
How do RPA project implementations work?
We often find the implementation process broken down into six stages.
In Discovery and kickoff, the initial implementation team assesses the potential automation for their complexity and feasibility, determines estimated timelines and efforts required for successful delivery, and sets up overall expectations for the project with the customer.
Solution Architect
- Walks through the process at a high level in the Discovery workshop, capturing details in the complexity calculator, if desired.
- Provide final judgment on process complexity and estimate required effort.
Project Manager
- Schedule and lead kickoff calls (often happen concurrently with initial discovery).
- Manage overall engagement using the project management template.
- Set expectations with customer business and centre of excellence on project plan timelines and requirements.
- Establish regular update cadence with all business stakeholders (i.e. weekly update call).
- Keep weekly monitoring of team hours billed and escalate any delays/overages concerns.
- Ensure project milestones/deliverables and assignments align with the project Statement Of Work (SOW)
In Process Analysis, the implementation team analyses and identifies the requirements of the customer’s processes. The degree of automation is decided based on this analysis (and on the complexity of the process), and as-is and to-be process flows are documented to inform the creation of a future state solution.
Business Analyst
- Walk through the process with the Subject matter expert, capturing all the as-is steps, and mapping the to-be steps. UiPath Task Capture is a tool which can simplify this part of the process.
- Collect any existing Business Requirement Document or other process documentation from SME.
- Complete Process Definition Document (PDD) for the process.
Solution Architect
- Validate that documented to-be steps are suitable for automation.
- Work with business application teams to ensure adequate test data is loaded into relevant systems for development and unit testing (can work with the Project Manager on this).
- Work with the Business Analyst to finalize the process scoping.
Project Manager
- Support the Business Analyst in setting up Subject Matter Experts walkthrough sessions.
- If changes to the scope of initially agreed-upon work are required, put in Change Requests as needed.
- Request and track all system access requests needed for development/testing.
- Get documented Process Definition Document (PDD) signoff from the business.
In Solution Design, once the business requirements of a process are finalized, the technical team designs a future state flow and maps out the various modules that’ll have to be developed to complete the automation.
Business Analyst
Validate that the to-be flow in the Solution Design Document (SDD) matches the business requirements captured in the Process Analysis stage.
Solution Architect
- Lead the development team in whiteboarding all the modules and components.
- Create the to-be process flow and the Solution Design Document (SDD).
Project Manager
Share the Solution Design Document (SDD) draft with the business for preliminary agreement, contracting on the potential changes to be made during development.
In Development and Unit Testing, the modules outlined in the design whiteboard are created by the development team, using the Process Definition Document (PDD) and Solution Design Document (SDD) as references. Created modules are tested individually to ensure they run successfully in controlled test settings, before larger-scale integration testing (next stage).
RPA Developer
- Build code modules as outlined and assigned (either as workflow files or libraries, as needed).
- Conduct unit tests on created modules as development progresses to catch and fix any bugs that may arise.
- Ensure code is in line with development best practices.
- The Solution Architect supports RPA Developers through constant mentoring and involvement in the learning process. Thus, the RPA Developer should reach out to the SA for guidance.
Solution Architect
- Track completion of modules against whiteboard plan, editing/adding new ones as needed per developer feedback.
- Conduct ad hoc code reviews to ensure developer code quality is in line with best practices laid out in the code review rubric.
- Create a test plan for User Acceptance Testing (UAT), containing detailed descriptions of all the “happy paths” and the business exception cases which have to be tested before the deployment.
Project Manager
- Secure time with SMEs for UAT.
- Work with business (and technical lead) to ensure enough test data is loaded into relevant systems to carry out UAT (in line with all test cases laid out in the test plan).
Users mainly complete User Acceptance Testing (UAT). The implementation team oversees the process itself in coordination with the business. Based on a test plan created by the team, all potential ‘happy-path’ and business exception scenarios are processed by the robot in the pre-production environment to ensure that it’s performing per all agreed-upon requirements.
RPA Developer
- Break-fix as needed, per testing results.
- Finalize process logging (in line with logging guidelines) and sync standards with the customer for post-deployment care.
Solution Architect
- Conduct UAT with business against all test cases-complete test plan.
- Conduct final code review(s), per any changes required during UAT.
Project Manager
Get a signoff from the business once User Acceptance Testing is complete.
In the Deployment stage, once the UAT is complete (with business signoff), the final process packages, libraries and assets are migrated to the production Orchestrator and set to run with production robots, which must have access to the production instances of all the applications in scope. Hypercare is a limited period which comes right after deployment. At this stage, the implementation team pays close attention to each process running in production. Usually, hypercare entails daily sessions where cases run by the automation in production are reviewed by the CoE and process SMEs, and any errors or issues are quickly patched and re-pushed to production.
RPA Developer
- Break-fix as needed through agreed-upon hypercare period.
- Monitor logs and review any exception cases that occur.
Solution Architect
- Finalize operational handbook – Development Specification Document (DSD) – together with the RPA Developer.
- Set up Continuous Improvement/Continuous Development models (if needed by customer).
Project Manager
- Ensure all necessary pre-deployment tasks are completed, per the Deployment Checklist Template, and follow up on post-deployment tasks to ensure they’re completed on time.
- Set up hypercare review sessions with CoE/Business as required to cover results.
- Set up final knowledge transfer session and handoff.
- Ensure all deliverables have been completed, signed off on, and delivered to the customer per Statement Of Work (SOW).
Congratulation
