- The definition presented in the last lesson was comprehensive, but was also a bit technical. So I'd like to introduce a real world analogy that often helps me to explain RPA to enterprises just getting started. Imagine you've just hired someone new to your team. It's your role to train them on how to perform their new job. On their first day, you might start by covering the high level mission of the team. For instance, if you run the payroll team, the mission is to pay the staff, and to do so accurately and on time.
You might, then, move on to teach your new team member which systems are necessary to perform their job. Next, you'll teach them how to log in to the systems. Over time, you teach them the rules and actions they need to use to complete more complex transactions. Depending on the process, you'll also wanna train them on events that happen less often. In this case, like bonus payments or final paychecks for anyone leaving the company, or other more esoteric transactions. Eventually, your new hire will have learned their job, and will be fully self-sufficient.
And hopefully they remember how to do each process as you've taught them. But you know that, somehow, everyone starts to deviate from the proper procedure, and we've only discussed one team member. The same set of skills and procedures has to be taught to each new person who joins your team. In comparison, RPA can be a much better solution. The same rules and job procedures can be configured into an automated agent, or digital laborer, as some are calling it. This new digital team member is then able to perform a process faithfully and accurately every time.
And if you need to grow the team to handle higher transaction volumes, you simply replicate the configuration, scaling up or down as needed. Think of RPA like a process flowchart or something you might see illustrated in Vizio. In such a diagram, just like in work procedures, you have a start, actions, decisions, and a resolution. All the potential outcomes are determined by the programmed rules, so they won't deviate by themselves. So, a less technical definition of RPA is simply this.
It's a class of software that allows you to transact in any IT application or website typically in the same way a human would, to perform complex rule-based work. To assist you in educating others in your organization, we have made a poster you can download from the exercise files section. Please feel free to share and distribute the definition. Being on the same page is one of the most important places to start.
- Explain what swivel-chair integration includes.
- Recognize when RPA would be most effectively employed.
- List the factors to consider when evaluating different RPA software.
- Name the three stakeholders who benefit from RPA in a triple-win model.
- Recall the two factors used to evaluate the merits of a process becoming automated.
- Identify subtasks that can disqualify an entire process as an RPA candidate.
- Summarize why automation is not always a good choice for a process.