We all know that RPA, Robotic Process Automation, is the automaton of processes executed by humans leveraging applications that provide a business or other need that is satisfied electronically with little thought.
Or as others have called it, the automation of the swivel chair. If we consider that RPA is automating those tasks, then RPA as a service could be defined as the payment or cloud-based offering of the automation of those tasks.
So how does that work, and why is it different than RPA as a software?
Robotic Process Automation As A Service Defined
The cloud software concept is pretty self evident. You buy the offering that the vendor is providing on the cloud, where they manage the software and let you have access.
Generally this costs less up front, but over time it can have some pitfalls, specifically if you are working with business critical systems, which RPA undoubtedly would be. The other problem that can occur is simple access to other applications as you run from the cloud.
When systems are outside your corporate firewall, there generally is a technology guidance you should be prepared to follow.
Pro’s: Initial costs, Infrastructure setup, latest and greatest version and access to full suite of applications. Possibly the biggest pro is you can focus on getting the process automated that you will see the best value out of, and can focus on what is critical to your business.
Con’s: Pricing can be confusing, lack of control, you may be able to do it better, can’t capitalize.May cause IT to throw up roadblocks as you are effectively automating out their control.
Robotic Process Automation As A Software Defined
You have the software, install it on your servers and laptops, it runs under your control. You have the responsibility for monitoring, upgrading, deploying.
Pro’s – You have the flexibility to set up your install as you see fit. Total ownership of processes and automation created. Greater understanding of the application and its use. Tends to get interested in IT since it will increase their budget.
Con’s – Setting it up can be new and exciting(read between the lines here). You will stumble, and hopefully it isn’t so much that you just quit using the software. You will need to understand out of the gate what type of RPA software you need as you don’t want to incorrectly purchase licenses. I have personally seen a company buy 1000s of bots to only have 60 working after 2 years
RPA As A Service vs RPA As A Software – Which Is Best For You?
Which is best for you/what do you really want?
There are some internal observations you should be making about you and your company to answer this. If you are a small to midsize business, generally RPA as a service is a good option to understand the software and limit the costs.
Further it allows you to focus on the reason you are here, which is to automate human processes and optimize your return on the automations. This isn’t to say that if you are an SMB you can’t have your own COE.
I would suggest that you shouldn’t do this if you aren’t a technology company or have a very adequate IT staff with the infrastructure to support it. Lanshore is a small business with its own COE, but that is simply because it is a service we provide, and understanding what it takes to get this type of endeavour setup, I would recommend against it unless you think it is critical to your business, and the details are proprietary.
If you’re a large organization you likely have the means to create your own COE. Most do because you want to control things that are as important as generating invoices, quality control, HR onboarding, and a myriad of other mission critical functions.
The beginning of the journey will be identifying first the list of processes and type of process automation that you will want to do. This is critical as it will determine what type of software you need to buy. If you intend on having people kick off the processes themself, then you will have unattended bots, but if you want it to run with no human interaction that will be attended.
Once you have determined this, you will need to see the setup of the hardware and understand what the configuration needed is. I would suggest this be done prior to purchase of a software as it can be a slightly intense process.
I would say the most important factor in the decision of SAAS vs On Premise can be made here, as you should have an idea of the cost and pain involved.
In either case you must emphasize documenting the human process and capital that have been created over the years, and that you are trying to automate. You’re going to have to do it anyway to determine if the project is successful and you get your ROI. It is important to, because if something changes, you need to be able to go back to the beginning and why.