Quanton's World of Business Process Automation

The risk of choosing the wrong technology is that an RPA programme will fail to scale, fail to deliver benefit or being abandoned.

According to Mary C. Lacity and Leslie P. Willcocks, in their book Robotic Process Automation and Risk Mitigation, in 2016 about 39 tools were being sold as “RPA” and about 120 tools were being sold as some form of cognitive automation and directly state that “because of the hype and confusion in the marketplace, clients risk choosing the wrong tool(s), too many, or bad tool(s).

A topic we discuss thoroughly in our guide to preparation and early stage planning, Choosing the right Robotic Process Automation (RPA) tool is neither a quick nor a straightforward process. Lacity and Willcocks further explain “because the space is relatively new to many clients, it is difficult to assess the actual capabilities and suitability of these tools, Clients must be aware of hype and “RPA washing”, a term which refers to companies investing resources into advertising and marketing.

Ratings from independent research gave scores ranging from 1.00 to 4.00 for deployment, governance and security in leading RPA technologies.

For example every tool we have looked at claims to offer enterprise-grade security. In 2017 Forrester Research published a report which reviewed “The 12 providers that matter most and how they stack up.” Rating attributes from 1.00 (low) – 5.00 (high) the scores for Deployment, Governance and Security ranged from 1.66 up to 4.00. The same was valid for architecture with scores ranging from 1.99 up to 4.33 and breadth of use case with scores ranging from 1.60 – 4.10.

Source: The Forrester Wave: Robotic Process Automation, Q1 2017

The inherent challenge is likely to be the lack of publicly available information to support comparisons and the knowledge of businesses to know which questions to ask or focus on. 

Notwithstanding extensive evaluation criteria, and in addition to standards we take as a given such as fit for the use case, architecture and exception handling, our suggestion is placing added focus on the five attributes which will tend to distinguish technologies.

1. Scalability

It is our observation that all RPA technologies will claim that their solution is scalable, but there are differences to what degree the solution is scalable and how it would scale.

We have seen an enterprise which had a locked room full of laptops because of the licensing model of the technology they used requiring one machine per software licence.

The assessment of scalability should not be limited to hosting but more importantly to maintenance, management and control of processes. We are very clear to say ‘processes’ and not software in this instance. As organisations scale their programmes, the activity of centrally controlling, maintaining and managing the processes creates a new dynamic that organisation will not have experienced in the past.

Take for example an organisation completing a significant system replacement, that affects 40 processes which are automated. What would be the effect for RPA and what would be required to update the automated processes? System replacements do not happen every day, but even system updates which occur as a standard course of business can have the same effect; For example, a significant part of a system changes, i.e. the login screen or a fundamental attribute changes, like a security criterion.

Architecture should also play into considerations around scalability, an area where technologies are highly differentiated. For example, there are technologies which have highly modular based designs, others that are out of the box, others that are friendlier towards customisation and some which work better with specific technology stacks than others. By now it should be evident that the issue of scalability is complex and requires a concerted effort from across the business to assess.

2. Support

As a standard aspect of technology evaluation, most organisations will naturally consider support. However, this will traditionally focus on the software aspects of support and the processes associated with the technology itself, i.e. version management.

A fundamental difference which we encourage organisations to remember is that automation is as much about the process and the capability as it is about the platform.

Therefore, support is required to maintain process delivery. What assistance will be available to help the business rectify an issue within a necessary time-frame if automation fails on a business-critical process?

The example provided focussed on issue resolution but what about pro-active support. To give another example consider the effect of small inefficiencies in technical configuration. While programmes are operating at small scales the Absolute impact is minimal, but these can lead to substantial costs as programmes begin to scale, magnifying the impact of inefficiencies. What support does an organisation have in place to monitor, identify and advise on technical attributes which could be addressed to improve efficiency or reduce risk?

Ultimately the encouragement to organisations is to investigate what support is available and to look beyond standard software support.

3. Security

Like scalability, all technology platforms will claim that they offer enterprise-grade security, but the actual definition of this can vary from technology to technology.

Referring to the example used in the introduction Forrester Wave gave ratings ranging from 1.66 to 4.00 for deployment, governance and security. 

When we consider for a second what automation technology is doing, which is necessarily processing business-critical processes likely using customer data, the implications to privacy as well as the security of sensitive commercial information can become very evident.

4. Licensing

We would expect that licensing would appear as a standard evaluation criterion in a procurement process, but it is worth focusing on in greater detail.

Licensing is an area where technology platforms have tended to differentiate themselves with price and structure designed to support their market penetration and customer adoption strategies.

To offer an example of some of the variance that occurs, some providers offer free community editions of their software. Selected providers have separated the functionality of ‘robots’ requiring separate licenses for each capability and contrasting this approach there are license models which provide full functionality within a single license from the outset.

Increasing the complexity some purchase models require minimum bundles, while others can be singular, and, in some cases, there are minimum commitment periods.

As a final point of separation, licence models can either be constrained to single users or have unlimited users. There is no right or wrong license model, only the model which will be most useful for the needs of your organisation.

Our encouragement is to consider the end state of your Robotic Process Automation (RPA) programme. What appears more cost-effective now may become significantly more expensive as your programme scales to the level which you are aiming to achieve.

To offer an example, we were recently told of a 200-seat call centre in the US who compared the cost of two preferred technologies. One technology was significantly more cost-effective at the small scale the organisation was planning to initiate the programme however once the investment was compared for the programme at full scale, which the organisation expected to reach in 18-months, the result was reversed, by a significant margin.

Be aware of the end state and consider the impact of licensing both regarding initial launch and concerning the scale your organisation plans to achieve.

4. Governance

I recently saw a presentation discussing differences in governance, and we came to a slide titled “When Does 2 + 2 = 5?”

The title was facetious, but the presenter proceeded to provide an example where the script of an automated process was changed, resulting in a different outcome when the automated process was re-run. The issue was that no record or log that the script was changed had been made.

I don’t raise this example with the intent of suggesting any product is of lesser quality but to point out that, like security, there are considerable differences in aspects that would be considered of high importance to most enterprises.

A question I have frequently heard is what’s to stop the robots being used for fraud. Let’s be very clear that the robots don’t commit the fraud. People commit fraud. The first question to ask is how the architecture of technology prevents examples such as these and the second question is if someone were to try how it would be monitored or audited.

As a closing point, our encouragement is that organisations look to the future as much as they are focussing on ensuring the success of an RPA programme now. At a recent conference, concerning ai, Steve Guggenheimer from Microsoft quoted “it’s too early to do everything, but it’s too late to do nothing”. Our observations of the market support this, and while for the better part commentary around ai and cognitive intelligence is still hype, there are pockets of genuine and compelling use cases beginning to emerge.

The real opportunity with RPA is not just the automation, but the ability to virtually integrate and connect systems. Therefore, for us, a key aspect of sustainability links to the product roadmap of technologies and how they are preparing to integrate with and enhance the use of other technology concerning their platform.

The reality is that RPA is both an investment and at the very least a mid-term partnership both regarding the technology selected and the partner supporting the implementation. To continue to raise the point that New Zealand (and globally) we are in the early stage of adoption where there is limited knowledge and experience, one of the best ways organisations can mitigate risk is pro-actively invest in due diligence processes. Don’t stop with a tick box exercise. Do not hesitate to go as deep under the hood as you feel you need to, to feel comfortable that a technology solution has a strong alignment to the needs of the business, both at the time the programme launches and about the planned future state of the programme.