Software as a Service, or SaaS, has grown increasingly popular over the last few years as companies embark on digital transformation initiatives. SaaS is especially attractive to businesses looking to reduce the upfront cost, risk, and resource consumption associated with software ownership. The instant availability of new software releases also reduces dependency on IT for implementation, management, and troubleshooting.
The concept of SaaS can be applied to Robotic Process Automation (RPA) as well. Recently, RPA technology vendors have started introduce their own SaaS models, known as Robotic Process Automation as a Service (RPAaaS). RPAaaS can mean different things depending on the vendor. It can refer to the consumption method of the RPA software, the availability of the software in the cloud, or something that looks a little more like RPA services delivered through a Managed Service Provider. These differentiators can have a significant impact on RPA’s total cost of ownership as well as its return on investment, which we’ll explore in greater detail.
RPA Services vs RPA-as-a-Service
First, let’s clarify that RPA services are not the same as RPA-as-a-Service. This is a subtle nuance in terminology, but the two experiences vary greatly. RPA services providers do just that: they provide RPA services. These vendors are referred to as Managed Service Providers, or MSPs, who offer a wide variety of business services. MSPs partner with RPA technology providers to sell their services layer over the RPA software. The total cost of ownership can be especially difficult to calculate with the RPA services model. You have to account for the licensing fees, upfront and recurring, from the RPA technology provider in addition to the service fees from the MSP. These service fees can encompass anything from RPA consulting to entirely building and managing the RPA initiative on the client’s behalf. For example, MSP contracting is typically broken out in phases, which could include proof of concept (POC), consulting, process selection and prioritization, infrastructure setup and build, everyday production and monitoring, change management, RPA personnel, and infrastructure maintenance. Each phase priced separately, with unique service level agreement (SLA) stipulations at every phase. Over the lifetime of the program, it is on the client to track the entirety of the engagement’s expense to manage a proper TCO calculation. Of course, if the client ever wants to leave the MSP, they are stuck managing an implementation with which their employees are not familiar, making it incredibly difficult to take it in-house, much less switch providers.
The Various Flavors of RPA-as-a-Service
The RPA-as-a-Service model being offered by the majority of RPA technology providers looks a bit different from what consumers have come to expect with SaaS models. The complex licensing models they are notorious for, which we cover in our TCO calculation blog, have not actually gotten any simpler, they have just moved to the cloud. Each software module is still priced separately, now with an added tier of SaaS pricing options, like consumption- or outcome-based pricing. For the majority, this SaaS-esque pricing approach is still being paired with RPA services provided primarily by their MSP partners, or through their own services layer.
It’s important to note that cloud-native RPA is not without its setbacks. For companies who have not entirely moved all their systems and applications to the cloud, this promise of seamless interoperability remains elusive. Cloud environments for RPA are also not without cost and maintenance responsibilities. Regardless of the provider, whether RPA is deployed on-premises or in a cloud environment, robots still need dedicated space to run. As the automation initiative grows, the infrastructure must grow too. The volume of work to be processed and the speed at which it must be completed will further drive virtual machine requirements. Depending on the cloud model currently in place, robot consumption is a cost that will need to be factored into TCO calculations. Of course, if you have a contract with an MSP to manage infrastructure, plan on a service fee on top of the actual cost of infrastructure expansion as well.
The HPA Difference
Ten years ago, when HPA first got its start, RPA was a relatively foreign concept. SaaS wasn’t close to garnering the popularity it has today and the concept of RPA-as-a-Service hadn’t been introduced in the marketplace yet. In an age where every software company recouped development expenses immediately, HPA was the lone RPA provider offering flexible, transparent pricing models for RPA services utilizing our own technology. The purpose of this approach was two-fold: make RPA accessible for clients of any size and ensure their success with applied automation expertise.
Early on, we referred to our approach as “Robots-as-a-Service”, but there is so much more to it than selling robots. RPA-as-a-Service isn’t solely about selling technology with convenient pricing models; it’s about ensuring clients succeed using the technology. To achieve this, HPA is continually incorporating years of automation experience into our technology, implementation cycle, and robot operating model. We have built a vast library of over 800 reusable, customizable components across hundreds of applications to expedite implementations without sacrificing quality. We are investing in APIs to produce more stable scripts and accelerate runtime. We have also re-engineered our core technology to be more lightweight and maximize infrastructure consumption.
Today, our approach remains the same. We will continue to invest in our technology and our people to deliver scalable RPA solutions with straight-forward pricing that accelerate ROI and reduce the total cost of ownership for our clients.