Does Your RPA Vendor Allow You to Scale?

One of the most contentiously debated topics related to RPA is its ability to scale. In order to answer the question, one must first define what scalability is. When we talk about RPA scaling, what exactly needs to scale, and how do we know if we’re getting there? As you can imagine, scalability is a complex matter. This is why success criteria and supporting metrics vary from organization to organization.

In order to determine whether your RPA program is poised for scalability, you should ask yourself the following questions:

• Can we cost-effectively accommodate workload demands at all levels (low, medium, high)?
• Can we accommodate asset reuse in an agile, secure, and uniform fashion?
• Do we integrate seamlessly within our organization’s greater digital transformation initiatives and infrastructure, or have we become just another silo?
• Have we acquired the requisite skills to, either internally or through a development partner, implement RPA projects consistently, iteratively, and cost-effectively?
• Are we allocating the proper resources required to: manage, remediate, and evolve the automations we have in production, or are they dying on the vine?
• Have we selected a vendor that allows us to scale linearly?

While each of the questions listed above can be the subject of its own whitepaper, let alone a blog, this blog focuses on the last question: “Have we selected a vendor that allows us to scale linearly?”

What Does Scaling Linearly Mean?

Within the context of this discussion, when we refer to scaling linearly, we mean three things:

• Does the selected RPA solution allow bots to be spun up dynamically to accommodate incremental load?
• Does the selected RPA solution allow for the prioritization of automations to share load?
• Is the selected RPA solution licensed in a way to accommodate transaction-level, not bot-level, incremental scaling?

Most vendors can technically accommodate the first two items for both attended and unattended bots. Centralized asset management and the use of virtual machines and elastic cloud computing can scale to accommodate load in all but the most extreme cases. The thornier issue is the last item: does their licensing model allow for incremental upscaling and downscaling?

While most vendors have adopted subscription licensing models, those models are still based on the number of tooling seats and the number of bots deployed. That model certainly seems logical from their perspective as software companies. But are they serving the needs of organizations seeking more modern, on-demand–oriented solutions?

This is precisely why we license all parts of the KnowledgeLake platform, including RPA, on a transaction consumption basis. And it doesn’t matter whether those transactions are consumed via our user interfaces or via API calls when the platform is leveraged as a service. Most RPA vendors offer licensing subscriptions that allow for growth via tiers of service.

For example, one vendor licenses its unattended bots based on some pre-defined number of varying automations that can be run per production bot. This requires careful planning and scheduling to keep licensing costs down. Another offers a license where only one automation type can be executed per bot. By definition, this method restricts scaling by forcing scaling in a stair-step pattern.

The bottom line is that these and other tiered models encourage customers to purchase over capacity today in return for tomorrow’s growth. The problem with these models is that they force organizations to scale their RPA program to conform with licensing rather than the other way around: in other words, linearly scaling licensing with growth that is natural and organic; growth patterns that are different from organization-to-organization.

By employing a transaction consumption-based licensing model, we encourage our clients to:

• Scale at their own pace via a model that is the ultimate in transparency (pay for what they use where value is delivered—i.e. in production).
• Allow every qualified developer to create automations on the platform in a managed environment—no need to worry about having enough developer seats.
• Distribute a bot on every desktop and only pay when workers employ them—tolls based on usage versus rent for the right to use.
• Be less conscious of project selection and configuration management designed to fit within a preordained licensing structure that molds behavior rather than encourages support for business opportunities.

How much more flexible could your RPA program be if, from a vendor licensing perspective, the cost of executing one million automations on one bot was the same as running one million automations on a million bots? That is scaling linearly.

For more innovative thoughts regarding transaction processing and intelligent content automation, keep up to date with our blog.