If you look at an RPA ISV or consultant’s datasheet, you are sure to come across the bullet point; “RPA as a Service” (RPAAS). Unfortunately, a bullet point is usually all you’ll get with little to no elaboration. I’m guessing that’s because while many providers in the space feel compelled to advertise an RPAAS offering, very few have solidified what that offering is and are often “winging it”, based on shifting customer requirements and tolerances. As frustrating as such “vapor service” may be to customers, it is not surprising given RPA’s relative nascent stage of maturity coupled with the fact that, by definition, RPA involves automating and integrating internal systems which can make crafting an RPAAS offering tricky. However, as an RPA provider, my company, RatchetSoft, also promotes an RPAAS bullet point so I feel a certain amount of civic responsibility to, if not clearly define RPAAS, at least share some of what we’ve learned as a so-called “RPAAS provider”, pose some real-world considerations, and put some meat on those RPAAS bones.
People, Process and Of Course, Robots
To some, RPAAS is merely a cloud-hosted RPA stack where bots physically execute automations either in the cloud or on the customer’s servers or VMs. While that is an important piece of the puzzle, it is merely scratching the surface of what RPAAS can and should be. Most of the major RPA vendors have relatively comparable technical offerings because there are only so many accessibility, control injection, screen OCR and UI element manipulation tricks in the Automation Architect’s bag. Sure, some products do certain things better than other products do, but most of these tools, when put in the hands of a skilled and experienced team that is following a well-honed project methodology, can deliver the goods. But if that is the case, why do a lot of RPA projects still manage to fail? Don’t blame the bots because it’s rarely their fault. One of the worst kept secrets in the RPA space is the gap that exists between the number of qualified practitioners (in terms of skills and experience), and the number of projects chasing those practitioners. This gap is the main reason why many leading RPA vendors have recently introduced their various “you too can become a certified RPA professional” academies, universities, and centers of excellence. Training qualified process designers and developers on methodology and tooling while also helping them gain real world experience leads to shorter and more successful project cycles. Successful RPA projects rely on skilled and experienced people with a tested and repeatable plan as much as they do upon solid bot tech. So, if you want to be an RPAAS provider, in addition to tech, you need to bring capable people and success-oriented processes to the table. Good tech alone won’t cut it.
The RPA Stack
As an RPA tech provider, it pains me a bit to say our competitors are good too, but they are. Sure, if you call me, I’m happy to tell you all the wonderful capabilities we believe set our offerings apart from our competitors, especially when it comes to attended bots, white labeling and our integrated human and bot runtime management tools. But in terms of core bot functions; managing process flow, being able to reliably access application screen data, manipulating controls, logging, etc., we all do that pretty well. So the stack you use usually comes down to the following factors: 1) your comfort level with the automation authoring tools, 2) runtime management capabilities, 3) licensing and pricing options, and 4) breadth of support. Factors that are not hard to figure out. However, when the stack is offered as part of an RPAAS offering, things get a little more complicated.
Hosting RPA infrastructure in the cloud to allow for the; authoring of automations, creation of jobs, publishing job submission interfaces (e.g. drop folders, REST interfaces, email, text or custom triggers), monitoring, real time user prompting, logging and video replay are all relatively straight forward. But what about the runtime bots themselves? Do they get hosted in the cloud as well? What are the considerations? If the bots are hosted in the cloud, then the customer will need to expose its internal applications outside its domain. Is that possible, desirable and compliant with corporate policy or government regulations? For example, we have several customers who are statutorily prohibited from transmitting their client’s personal data beyond its country’s borders. That being the case, the stack must be hosted in a location that resides within the client’s country of origin. Can the RPAAS provider do that? Alternatively, if the bots are hosted within the customer’s domain, what process is in place to ensure the bots are available? Scaling bots on demand becomes more complicated once the customer is responsible for maintaining each bot’s runtime environment. Further, regardless of where the physical bots are hosted, the RPAAS provider needs to work out the thorny issue of security. If the bots run in the cloud, how is the connection to the integrated internal systems secured? If the bots are physically running in the customer’s domain, how are the communications between the cloud-based stack and the local bots secured?
To complicate matters further, it is important to recognize that not all RPAAS providers are the creators of the RPA stacks they sell. We are starting to see system integrators, outsourcers and consultants becoming RPAAS aggregator providers and offering customers a choice of RPA stacks. While technology agnosticism is a laudable goal, in practice, offering all things to all customers rarely works out well for anybody. Over time, be it for practical, technical or commercial reasons, aggregators tend to lean towards, and become experts in, a limited, core set of technologies. The rest become more technical dalliances than viable offerings so be wary of pushing the RPAAS provider out of its comfort zone. If the key to success is focus, then customers who want to use a third party RPAAS provider (because of their people and processes), should partner with one that focuses its efforts on one stack unless there are compelling reasons to offer an alternative such as; unique advanced features, licensing options or price differential.
We’re In Production…Now What?
Once the automation is created and rolled into production, what is the role of the RPAAS provider? As a minimum, the provider must maintain the stack and all the monitoring and logging that goes with it. In addition, RPAAS providers should be prepared to offer the following services:
- Handling and clearing automation user prompts (usually the customer performs this role but increasingly, customers are getting comfortable with the provider handling this part of the job).
- Updating automations based on experience learning.
- Performing sandbox testing with new versions of integrated applications (preventative maintenance).
- Providing quick response, break/fix services when unforeseen environmental changes break an automation.
Have We Figured Out What an RPAAS Provider Should Do?
Well, I don’t think we’ve arrived at a concise definition but I think we’ve established a framework around which a more substantive discussion can be had between customers and providers. So, the next time a sales rep drops a datasheet on your desk that contains that RPAAS bullet point, ask if his/her company provides the following:
- Bring trained and experienced RPA professionals to each project who serve either as the prime design, development and deployment resources or at least work hand-in-hand with those teams in a mentoring role.
- Provide a well-honed, experienced-based methodology that guides each project by clearly defining tasks and roles and responsibilities associated with all the services it offers. Failure is not an option.
- Possess deep and focused stack expertise regardless of whether the provider owns or resells the stack being used.
- Maintain the runtime environment.
- Incorporate ongoing learning and feedback into automations in production.
- Provide automation preventative and break/fix services.
And of course, can they do all this at a reasonable price and terms that are compatible with your organization’s licensing requirements. Sometimes the ease of doing business with a company is just as important as the technical quality of its offering.