The Definitive Guide To Robotic Process Automation–for Humans
Last Updated on November 9, 2020 by Owen McGab Enaohwo
At SweetProcess, we weren’t sure which topic we should deal with first when compiling this guide on Robotic Process Automation. How to implement RPA successfully? What not to do when deploying the RPA bots? Or what is RPA and how is it different from, say, Machine Learning (ML) and other similar processes? But since it is somewhat customary to begin with a formal definition, let’s give that a try first.
The IEEE defines RPA as the deployment of a preconfigured software instance that uses business rules and predefined activity choreography to complete the autonomous execution of a combination of processes, activities, transactions, and tasks in one or more unrelated software systems to deliver a result or service with human exception management.
Quite a mouthful! We’ll break it down in English for you, no worries. However, you are here most likely because you want to know more about RPA to decide if you’ll invest in it. And so, RPA being a business decision apart from everything else it may be, we thought we’d show you exactly how such a decision ought to be arrived at without costing you billions and a possible loss of face, plus some totally avoidable employee discord.
If you don’t want to play along, just scroll to the content table and choose your poison. Rest assured, we cover everything that is RPA right here in the next 4,628 words that follow.
Robotic Process Automation Guide Table Of Contents
Chapter 1: Robotic Process Automation Implementation
Like we stated earlier, RPA is, among other things, a business decision. No matter how wondrous an idea it may seem to have mechanical critters running around doing your job for you, at the end of the day it is just a darn decision that determines how much your business will profit—or no.
Essentially, it is not all that different from deciding if every floor of your office building needs a different janitor.
Extreme, yes, but we wanted to drive home the point because this is where the mistakes begin—the novelty of RPA and frequently hyped expectations cloud the decision making process so much so that practical concerns and protocols are ignored and you end up going straight to the “experts,” itching to deploy tomorrow. Don’t be like that.
1.1 Getting everyone onboard
What does that mean, anyway? Obviously, you’ll be involving the board of directors or whatever is your topmost decision making body, but you’ll want to go beyond that.
Why? Because when you implement a shiny new process, you’ll want to get your employees to welcome it, take responsibility for it where applicable, and generally not be wary of it.
(And, since it is an investment, the more support you have for buying into it, the better chances you will have for getting your ideas approved as also, God forbid, if anything were to go wrong, fewer fingers would be pointed at you alone.)
There’s ample reason to be wary. Whenever something is “automated,” the most obvious consequence (or apprehension of a consequence) is that of a certain number of human employees will become redundant. It doesn’t have to like that.
As for taking responsibility—this is a biggie—since robotic process automation is a software implementation (the [auto]bots are really just another software program, albeit highly customized), does it fall naturally into IT’s domain?
Or is it Bob’s responsibility to oversee the automated process since said process is making Bob’s life a whole lot easier by taking care of the boring bits while he focuses on other interesting stuff in customer care or stock taking? (See? You don’t have to fire people to deploy RPA. More on this later.)
Or perhaps you should look to whichever company designed the bots for you because, well, if your IT department (or Bob) knew about RPA you wouldn’t need experts from outside. D’uh.
All right, now that we know a bit about the questions, let’s focus on finding the answers to those.
1.2 Identifying areas of deployment & preserving employee morale
You can deploy RPA if you have—let’s use a technical term here—boring processes run by human employees. Boring and repetitive. Where someone—let’s bring in Bob again—does the same thing over and over again during the first half of his shift. Inspecting invoices, for example, adding up expenses, sorting them, filing them and, finally, presenting them to whoever is his supervisor. There is no decision making involved unless a vendor has changed their contact number, maybe. Yes, this is a decision making process that the bots will not be able to handle.
How the heck does a changed telephone number create a decision making process? Well, you and I know that address, registration number, company name and contact person remaining constant, a changed number is just a changed number. And we’ll nod through it—perhaps not even notice the change. A robot will see that changed detail as an anomaly. And since it doesn’t know what to do about it, it will set that particular invoice aside. Bob can come back later and make a manual entry and, perhaps, instruct the bots that vendor X with contact number Y is the same as vendor X with contact number Z.
In this context, it may be pertinent to touch upon the different types of RPA which Bob could be working with—or not, since the last two versions would deal with things way beyond Bob’s current responsibilities.
RPA can be categorized into four versions which can be deployed simultaneously, and one is definitely not better or worse than another. The kind of automation you require for optimum productivity is the kind of RPA you will choose.
Usually deployed in the worker’s desktop and enables partial automation. Bob’s case above is not an instance of this in the true sense—this is more like if the job had two parts, one of which required a bot, and the other an analytical approach. Let’s say if the invoices needed to be grouped according to priority based on Bob’s impression of the vendors and other such intangible, unquantifiable aspects. The robot would do the sorting, Bob would line up the invoices according to priority.
A simplistic (but accurate) example would be what we have initially referred to—the mechanical sorting of invoices. The bots are deployed via server and are capable of performing more complex tasks including end-to-end management of all deployed bots in a given category. However, the word “unassisted” in this case really means “minimal.” Human intervention is still required.
This is where RPA gets truly unassisted while still retaining its RPA identity—but rather tenuously. This is not the kind of RPA we are talking about in this article. It is more akin to a limited form of AI, especially when you consider the fact that autonomous RPA is capable of creating advanced analytics, designing workflows, and is frequently context-aware.
If these terms sound vague, think Google Analytics and add to it the ability to provide you with a workflow based on your chosen parameters—or even the ability to determine what the optimum parameters ought to be given your website data. But not if that data is unprocessed and uncategorized—that is the single most important limitation of autonomous RPA.
This really falls under the domain of AI, and the fact that it is still classified as a form of RPA is most likely because it begins with RPA but integrates other forms of automation to make the entire process intelligent, capable of prediction and judgment.
Pure robotic process automation, which we talk about in this article, is not business automation. If you are unsure about the definition, please read Chapter 2 to understand the differences between machine lLearning, artificial intelligence, and RPA.
There is just one more type of RPA which we need to know about before moving on, and this, perhaps, is the most important one from the end-user’s perspective:
The name is kind of misleading: the coding is there, all right, but as far as the client is concerned, the user interface is friendly enough to permit more modification to the automation than the traditional RPA interfaces do. In other words, it is a no-code situation for you, the end-user. Think DOS vs. Windows and you’ll get the picture.
Having said that, the difference is not that vast—yet. And there’d still be a lot of work involved. But it is definitely a huge step toward the right direction as far as usability is concerned. If the option to have additional programming and modifications done in-house balances out the extra cost involved, you should seriously consider vendors offering this option.
Watch the video below to see how it works:
So now you know that only boring and repetitive processes that require little or no decision making capacity can be automated through RPA. But how does that automation help you? Especially when it jolly well doesn’t come for free?
We’ll refer to a case study here to understand that as well as take note of how a business can benefit from RPA without resorting to lay-offs and redundancy pay.
1.3 Case Study: Coca-Cola extends business services capacity and improves performance with RPA
They started with the finance division and then moved on to HR. All tedious and repetitive tasks that could be automated were automated. In doing so, they found scope to go deeper and mine more data that, when resolved by human employees, led to a better customer experience. And we all know what an improved customer experience does to a company.
What’s a long-winded article without images? Time for a screenshot:
We could blockquote the life out of that but since you can read it, let’s focus on two simple points here: extended and highly productive work hours, and re-skilling human workers and augmenting talent. That’s how RPA helps.
Oh, and this is how they prepared for success:
To identify relevant process candidates for automation and build a pipeline, Coca-Cola began by talking to internal SMEs that owned the most manual HR processes. Questions asked included: process volume, how often processes are handled, and how many hand-offs occur. These criteria were examined to determine which processes scored the highest for viability, posed the greatest risk and how many people were involved in the process. To provide a single source of truth on everything related to each process, Coca-Cola also put up to 85 percent of its HR processes into an intuitive online mapping tool. This insight enabled the company to understand how much automation could be applied to each of the 150 identified processes.
[Read the original case study.]
This validates what we have (more or less) stated already: get everyone onboard, identify areas that could do with minimal human intervention, implement RPA in such areas and, most importantly, re-skill your workers so that they provide value doing what they do best. People do work for money, but if you show goodwill to your employees, it would be very surprising if they don’t pay you back with loyalty, dedication, and enthusiasm.
That said, it is conceivable that in the long run, you will need fewer new employees. And your existing workforce will likely be a more satisfied and dedicated lot. If their work is not always challenging or stimulating, at least the bots will be there to take care of the boring stuff which can really suck the life out of intelligent personnel, and significantly reduce job satisfaction.
Further Reading: Cigen.com
1.4 Mitigating risks
Most of the risks spring from two factors: failing to choose the right vendor, and harboring unrealistic expectations. We have a separate chapter on the first one. Let’s examine the second one here.
1.4.1 Common Myths About RPA
- RPA is magic so it is okay to trip over yourself
It is just another thang. And a new one at that. And what do good businesses do with new stuff? Put them in a box, of course, to determine how safe they are. If you do not set up a test environment before deploying, you could invite completely unnecessary complications.
Unfortunately, if the desire to please top management outweighs rationality, this completely avoidable error could assume the form of a “diligent” adherence to a previously declared schedule. And result in an event with much fanfare that shows off the face of the future with sweaty fingers crossed behind the back.
If you are top management, it would be in your interest to ask for a demo before deployment. If you’re the one in charge of the deployment, do take care to explain that a test environment is not optional.
- RPA is where the bots do all the work
Kind of. It is not complete automation. As we have explained earlier, the bots cannot “think.” So you do need a human overseeing the process. The advantage is in terms of using human resources optimally. For a human being to work on repetitive tasks (when they are better employed at tasks that require intelligent decisions) is a waste of time. For that same individual to look over what the bots have done and decide if intervention is needed is perfectly fine.
And if this overseeing process is ignored, because an RPA assigned process runs faster than human operated ones, and without pause if you have the requisite hardware, any error has the potential to both go unnoticed and cause widespread chaos.
The solution here is simple: do not expect RPA to run on its own. That’s it. How you assign human employees to oversee a process, of course, depends upon the nature of your organization. And even though Arnold hates plan B, in this case, you’d better have one ready and tested to run the moment things go awry—and they very well could.
- RPA gets you profits
Yes, again. But not tomorrow. Or next month. It will take a while for the ROI to be visible. Meanwhile, you will have reshuffled your staff, reorganized the organization, and made efforts to understand where you’re at. That is a good thing, and you should see higher productivity and, hopefully, a more cheerful disposition all around with everyone taking interest in the novelty of your newly introduced automation.
This is not a problem, so we’re not even looking for a solution. You will want to focus on how productive you’ve become now compared to pre-RPA implementation and on how to run things flawlessly.
- RPA-run processes can be made even better
Okay, hold yer horses right there. Yes, they can be made better, but not by you or your staff unless you did create the bots on your own.
Remember how you went over everything with a fine tooth comb and identified what could be improved upon and to what extent? Don’t forget that research. You want better? Go to the vendor with that research and a detailed update on how things have been post-RPA. Don’t try to tweak things in-house (although it is theoretically possible to train your staff to do that).
- RPA will fix things
Nope. Not happening. If it can’t think, it can’t fix. Simple. You cannot implement RPA on a badly run process and expect it to get better. All you’ll do is make the badly run process run faster with more bad staff spewing out per second than before.
Again: RPA bots perform repetitive tasks. They do not provide intelligent solutions. If you have people dozing over tasks that are boring as heck and require minimal brains to get done, those are probably good for robotic process automation.
2. What Not to Confuse Robotic Process Automation With
2.1 Artificial Intelligence
In section 1.2 We talked about how an RPA process would behave in case of a new telephone number on an invoice even when other elements like company name and address remained the same (the invoice would be set aside for human inspection). AI would know that other details (the company registration number, in particular) remaining constant, the new telephone number is not a deterrent to processing the invoice.
AI would “think” like a human being and use logic to come to a decision—something RPA is not capable of.
IBM Watson is a good example of AI. To use IBM’s words:
By freeing your employees from repetitive tasks, you can empower your teams to focus on more creative, higher-value work. With insights from Watson, you can predict and shape future business outcomes, while rethinking your practices and workflows.
As you can see, the first sentence appears to describe what we know RPA can do for us. But then we are told about the “insights” (a very human attribute) from Watson that can help us predict, shape, and rethink. It is almost as if we are being introduced to a human business advisor.
And here’s a list of what Watson can do for you:
Deepmind is another example of an AI platform but interestingly, here’s what is said about Deepmind for Google:
DeepMind for Google takes cutting-edge machine learning research pioneered by DeepMind and uses it to have real-world impact at Google scale.
In our context, this means D for G is using machine learning to create an AI experience with Google. Confusing? We’ll clear this up in a minute but first, let’s take a look at what the Deepmind AI has been up to.
- Reducing energy usage (for cooling) in data centers
- A more natural-sounding voice for the Google Assistant*
- The next generation text-to-speech capability to Google Cloud Platform customers and,
- Adaptive battery and adaptive brightness for Android phones among other things.
*Frankly, we did not find the wavenet and non-wavenet samples so different but here’s the research that is both impressive and promising. Only, the name is eerily similar to SkyNet!
2.2 Machine Learning
Machine learning is literally that: the machine (the software, actually) is fed enormous amounts of data over a period of time so that it learns to recognize, categorize and “act” on its own. No, it cannot predict like AI does, but it can “sift” through things smartly so that little-to-no human intervention is required. Your smartphone’s camera has a face detection feature which you probably take for granted. Well, that feature took hours of learning for the camera software to perform with any degree of accuracy.
There’s something called an “alt tag” in HTML that allows the name or description of an image to be added to the code when the image is placed on a webpage. This is so that screen readers can tell a visually-disabled surfer what the image is about (since “image.jpeg” wouldn’t be particularly helpful).
Apart from this, the alt tag tells the search bots what the image is about because the bots cannot view and interpret the image like we do. This, in turn, helps the search engines to deliver more relevant results (resolving whether it is “Jaguar” the animal or the car being one of the most frequently cited examples).
If you’ve been surfing the net long enough, you may remember playing the Google Image Labeler game where you’d have to label (or name) an image based on what it looked like to you. This was machine learning so that the Google bot could learn to identify images on its own. The alt tag is not redundant yet, but Google’s search algorithms can now identify images fairly accurately independent of it. Here’s an excellent article if you wish to learn more about this.
Summing up: AI & ML
For more clarity, let’s come back to Bob’s scenario. If ML were to be used, the software would be able to understand that everything else remaining constant, a changed telephone number is irrelevant. And Bob’s intervention would not be required.
But what if the total amount specified in the invoice were to be slightly out of proportion with the services rendered, especially compared to other bills for similar services in the past? Or if the miscellaneous category showed a suspiciously large amount? Some innocuous discrepancy in the tax category, perhaps? Some other tell-tale signs of irregularity like an unknown or unexpected category popping up? All these variables would be too complex to pack into a bundle and feed the machine for it to learn. In all such cases, where the software would have to mimic human insight and even instinct, Bob would require AI for complete automation.
2.3 Other Automation Processes
We thought of including these just to round off this section. Feel free to research them further if they catch your fancy. If you’re thinking of going into RPA, it can’t hurt to acquire a more comprehensive vision of the world of automation and artificial intelligence.
Natural Language Processing—computers read human language (to detect spam, for example) and turn the input (or the text) into structured data.
Natural Language Generation—computers write human language (think chatbots). Now structured data is turned into text.
Natural Language Understanding—computers actually understand human language, and respond (Hello, Google, anyone?).
This would be the enhanced version of optical character recognition (where you can scan a page of readable text into…a page of readable text, as opposed to just the image of the text). Read this excellent article for a better understanding of the concept and its uses.
If the idea of a software process acting as a real life, intelligent assistant confuses you, think super chatbots (really, really super), and then go ahead and read this article for further details.
The name says it all—computers analyzing data to wring the last drop of usefulness from it and giving you ready-to-use packages so that nothing is overlooked, and the total time spent on hunting and gathering (and analyzing, of course) is cut down drastically. For a more detailed account of how this works in real life, take a look at what Google announced some time back.
This isn’t an exhaustive list, but we suspect it will help you gain a better understanding of the various processes involved, and help you grow further once you feel you’re ready.
Chapter 3: Beyond Robotic Process Automation
There are a number of automation methods, and the best results are usually found in scenarios that are simple and can be fully automated using more than one such method. We’re talking about intelligent process automation strategy.
Scenarios that are simple—but time consuming and repetitive and involving different departments and individuals and processes—that’d be our ideal candidate for IPA. Why not complex processes? Because they are (at present) best handled by human intelligence with assisted automation where necessary. This is how things work best with RPA as well—which is just one facet of IPA and can achieve only so much on its own.
The goal is to be as productive as possible: automation just happens to be incidental to that goal. So, if you intelligently automate the small stuff, no one has to waste any time over them and can pay attention to things that bring in the big bucks—things like negotiating deals and generating goodwill through superior and personal customer support, for example.
This video demonstrates everything better than we could, and in any case IPA is beyond the scope of this article. We know you came here for RPA but we strongly suggest you watch these case studies to gain a better understanding of where your focus ought to be and just how productive you can get.
A hint, in case you’re too busy to spend fifteen minutes on the viewing right now: what if you could automate an employee’s onboarding process beginning with how they handle their first task through how it is processed all the way to the accounts department while keeping everyone in the loop at every stage? Here’s the link again.
Chapter 4: Understanding ROI and ROE
That would be return on investment (ROI) and return on effort (ROE). The first is easily quantifiable, but the second one, as you can guess, is an index of both employee satisfaction and the goodwill generated as a consequence. Implementing RPA, especially with reskilling (and not simply firing) your existing workers, takes a lot of effort in addition to the investment that procures the software and the hardware. It is important that you calculate your returns both on investment as well as on effort.
Since effort is best measured qualitatively, you will want to understand if you’ve been able to achieve increased employee satisfaction and if it has led to better productivity. If the two are not directly proportional, you’re doing something wrong.
As far as investment goes, it is often calculated under the assumption (which many vendors promote) that the robots will work 24/7. There could always be outages and there should logically be downtime for maintenance. Ask your vendor to clarify these points, get an estimate on how many hours per day or month the bots will actually work, and only then try to project your returns.
Typically, after implementation, RPA should:
- give you almost completely error-free productivity
- allow employees with extra time for strategy, customer relations activities which,
- in turn, ought to give you better productivity
RPA should also:
- clear backlog
- increase productivity in specific areas compared to how human workers fared
- eliminate the need to hire new employees since old ones have been reassigned
- which should profit you in terms of money in cost avoidance and cost savings
Finally, RPA should simply make you more capable of providing both on-demand services and catering to a larger number of customers.
If you chalk out a clear map of how things used to be along these lines and how they are progressing now that you have implemented RPA, you should have an equally clear and quantifiable idea of whether your investments are bearing fruit and at what pace.
The first couple of months or years (depending upon how extensive your set up is) ought to give you enough data to make decisions about deploying more robots. After which you will go back to the initial phase of identifying areas of deployment—newer ones are likely to open up by this time. Or, if you had chosen to test things out in only one of your several identified areas, perhaps, you will now prefer to automate all of them one after another.
Either way, data is your friend (when is it not?) and close observation—for that qualitative assessment of your workforce. And, of course, a clear plan of action and the patience to see it through.
Chapter 5: End of the Journey—Choosing an RPA Vendor
The previous chapter outlines what you can typically expect of RPA and equips you with the relevant questions to ask your chosen RPA vendor. But the question is, who do you choose, and how? Especially when there are so many to choose from and a cursory search turns up everyone’s favorite list of vendors which is confusing, to say the least.
As for us, we are not in a position to offer you an estimate regarding how much you’d have to invest initially—there are simply too many variables. Thankfully, if you take a good look at the problem, the solution is simple enough. Here’s the question we need to answer:
How to choose the right RPA vendor for your business?
We put ourselves in your shoes after assuming that you are a business which has been doing fine so far but wants to do better and invest in RPA even though uncertainty prevails about…well, pretty much everything.
And we realized that:
- a free trial would be great.
- as would a freemium subscription.
- and multiple subscription and licensing options to choose from.
- and web based and installed options.
- plus the opportunity to sample all three types of automation, attended, unattended, and no-code (taking advantage of the free and the freemium).
Sound good? Go ahead and download our (very short) list of the top providers for RPA that fit the description.
In case you want more options, we have also included two different resources guaranteed to cause an information overload about RPA vendors and their offerings.
We also added a further resource for good measure to clarify any lingering doubts you may have on how to go about choosing RPA vendors.
We’re sure this bundle will help you get started in just the right direction to get your first RPA project off the ground. Do come back and let us know in the comments how you fared. And don’t forget to share this article with your aunt Matilda and whoever else might be interested in a no-nonsense, comprehensive guide to practically everything about robotic process automation. Good luck!