Understanding RPA
Every day we are surrounded by manual processes. Manual steps taken by a human to accomplish a set goal. These processes typically use a combination of user interface (UI) interaction along with some repeatable logic. Robotic Process Automation (RPA) describes tools that are designed to mimic these “manual” process taken by humans using the same UI interaction. Within the RPA tool, the process of mapping the steps and then allowing a “robot” to follow or execute the computer pathways, ultimately allowing the robot to operate in place of human.
A properly created RPA process can be triggered automatically or manually, populate data, move data, trigger downstream activities, document audit trails and even conduct complicated calculations. The RPA tool can also be scaled from an individual robot operating on standard desktop to enterprise servers with multiple robots performing multiple scheduled task.
Finally, one of the biggest fears is that RPA will replace the human workforce. While the goal is to automate repetitive tasks, this rarely leads to decreased staff. In most situations, the staff are reassigned to task that can’t be automated. In addition, 30-35% of the published RPA processes still require some level of human interaction. This fear should not discourage the automation of your processed and deployment of RPAs.
Formalizing an RPA Strategy and Roadmap
Many organizations rush to implement RPA and start a project. Regardless of the size of your project, it is best practice to build an Enterprise Automation Roadmap (EAR). The EAR is designed to map out and understand all the areas where the manual processing, keying [or rekeying], and data entry would benefit from an automated process. One must also understand that the RPA tool is unlikely to solve every unautomated activity in your organization. A properly completed EAR will highlight:
1. Processes that can be fully Automated [unattended processes] 2. Processes that can be Automated with Human Interaction [attended processes] 3. Processes that do not quality for Automation
One pitfall to be aware of and avoid is expecting RPA to fix a bad process. A bad process is still bad regardless of it being manual or automated. Bad manual processes should be addressed, and if possible, solved prior to mapping it for automation.
Below are some industry accepted guidelines to follow when identifying processes to automate.
1. Is the process suitable for RPA: RPA suitable processes tend to have a high transaction throughput of structured data, fixed processing paths that do not change frequently, and/or are rule-based activities.
2. Does COTS Software already exist: RPA is not a replacement or alternative for package software or services that already exist. RPA cannot be your Payroll system or order entry system. RPA is designed to reduce the manual entry required for these types of systems but not to replace the systems.
3. Which Areas to Roll Out and How: There is no hard-fast rule for these as each organization operates and thinks differently. Will you tackle the most challenging processes first? Maybe you tackle the areas that will present the most human resentment or acceptance. The key to understand here is to simply have a plan and a reason behind the plan. You will be asked to explain.
4. Handling the Politics of RPA: This is the world we live in; everyone has an opinion. RPA is not a topic that is exempt. Replacing human actions with automation [robots] will cause anxiety from those who feel their jobs may be eliminated. They will be less likely to want to show and discuss all the steps they perform. You must reassure them of benefits around automating some tasks. You will also face the group that will never believe it will work, even when shown. Identify the political obstacles in your organization and determine how to navigate through or around them early in your design stage.
5. How will you support? What happens if RPA Stops?: If something happens that causes the robot to stop processing, you must understand the business impact. Is the associated RPA process a critical process [i.e. Invoice Billing at the end of a Quarter]? Does the process require continuous monitoring? This type of considerations should be identified by conducting a risk assessment for each RPA deployment.
No Standing, Dive In
We liken RPA adoption to swimming. To learn to swim you must first dip your foot in the water and get wet. Your first RPA project will present challenges of change, fears of job losses and a mirid of potential resistance that can easily sabotage your first and future automation plans. Utilizing the guidelines presented here will assist in getting you swimming at the appropriate pace. Shamrock Solutions has positionedA itself as your potential swimming instructor when thinking RPA. Even if you do not want to swim at all, we can assist and drive your RPA projects from beginning to end. Also check back frequently to learn about some RPA case studies.
I ask you again, Do You iRPA?
Elroy Taulton, Development Manager