When you travel through the froth, reach to the core and witness the reality, RPA does not look like what you were told by the Sales reps and the Service providers. RPA as a concept certainly got a potential for cost savings. Is RPA useful at all? – Yes. Should you look at RPA? – Yes, you must. Can you eliminate dependency on Technical People and let Business Subject Matter Experts automate the processes? – A resounding NO. Can RPA use an App Store? Yes, Yes and Yes. These are RPA’s promises and realities – RPA minus all the BS built around it. RPA vendors must concentrate on building a highly extendable and customizable platform not the individual skills. Although vendors can build a few necessary skills, it must be the job of developers

If you are a pragmatic person and keen to produce value with everything you do, you want to understand a concept or a technology for its true worth. Because of the forth created by Marketing people, this info is unavailable in ready-to-consume form. This article is intended to process all the crude info that’s freely available around RPA and get to the core of what it is truly capable of – at least as of today. If you are new to RPA, please refer to my previous post to get an idea of what it is.

RPA is incapable of empowering business subject matter experts to automate without the help of technical people. RPA is a platform that comes with a suite of tools that make automation possible. However, the current platform and toolset are inadequate and unreliable to achieve this technical independence. Here is a list of ares where I think the problem is.

Openness

Openness is my big concern with RPA. Currently RPA products are mostly closed environments. The vendors look at them as a platform that does not need to integrate with other non-RPA systems. If the vendors do not open their platforms up to other systems, it would be a disaster for them. For example, ability to trigger an automation task – may be exposing the script as a REST endpoint, ability to share application context or transaction context among RPA and non-RPA systems, ability to pass input/output parameters with native datatypes instead of passing through files – pass an array of integers vs writing the integers to a file and pass the file as input etc.

OS Openness

Most of today’s RPA products can run only on Windows machines. This means irrespective of your IT policies and guidelines, you are forced to use Windows servers(or desktops) to run RPA. For a few organizations that would be a showstopper.

For a few vendors, this restriction is partly caused by the technologies they used to build the product itself. For example, if a particular vendor’s RPA product is built using .NET framework, it cannot run on non-Windows platforms. Some of the RPA products heavily rely on Windows internal libraries directly (instead of abstracting it out) to achieve majority of the system level work. This is another reason why they cannot be ported to other platforms easily.

Code Openness

Most of RPA products allow you to write custom code and run them along with other standard activities. Technically they can allow this custom code to be written in any language and still be able to run it with proper execution environment – whether they ship the environment along with the product or provide a way to the admins to install and configure it. In my opinion, this is a great opportunity to RPA vendors to open up their environment. But most of the RPA products allow only one or two scripting languages to write libraries in. VBScript, JScript – are you really serious, guys? This is 21st century AND we are 17 years into it already. Wake up !!! No technology can have mass adoption without support of developer community. This is the way RPA vendors to get the much needed support from developers – support as many programming languages as possible to implement custom functionality

Platform Openness

In general, RPA platform itself is very closed. For technical people, developing automation scripts with RPA products is nothing less than torture. For example, the script you compose through dragging and dropping a few activities cannot be hand edited – Behind the scenes this script is nothing but a bunch of commands written in a sequence. However, most of the vendors won’t allow you to edit this script by typing. If allowed, this would help developers save a lot of development time. The scripts are stored in proprietary binary formats. This is a lot of inconvenience that could be easily avoided by exposing the textual format of the script to developers. Even if the targeted audience to these editors are non-technical people, RPA vendors can support a developer mode of the editor which will allow developers to do more sophisticated development – one solution does not fit all.

Open for extension – App Store

No general purpose platform can claim that it supports all the use cases that are ever possible in the world. Even packaged solutions such as SAP FI/CO or SD which are built for specific domains need customizations and enhancements for real world scenarios. How can a generic platform like RPA which claims to support any domain – whether it be finance or energy or any other thing in the world – think that the standard tool suite provided would be comprehensive enough for all real world use cases? This problem can be solved by an App Store – Let the developers around the world build general purpose and specific purpose automation tools that can be seamlessly plugged into the RPA platform.

Compound Deployment Artifacts

Today all RPA vendors expect automation scripts to be single files. I think for any serious real world usage, you would build a bunch of reusable libraries which can save developers a lot of time. Although building reusable libraries is possible today, there is no proper way of packaging a script along with all the required libraries. Support for building compound deployment artifacts is necessary. Think of a script as a bunch of files that are packaged into a deployable package.

Reliability of Tools

Although there are a lot of tools – such as Web Scrapper, OCR, PDF reader – shipped with the RPA platforms, they are unreliable for real world scenarios. For example, PDF reader let you highlight a text and copy it – but few products let you specify which page of the file this text is expected to be found or which pattern should be used to identify the text etc. This information will be implicitly determined by the tool itself. The problem with this approach is, the script developer won’t have any control on influencing the decision except he/she will highlight and copy and product will figure out the pattern. In real world, this approach won’t work very well. For example, for all PDF’s the text may not appear at the same location on the same page – if not, then the script will fail. Similar reliability issues are present with other tools too. Again the solution could be to build an adaptable UI so that if the developer wants to work with the script at a higher level of sophistication, they can. RPA vendors must not keep the control with them – they must give it to the developer/implementer.

Cloud & CI/CD Support

It’s mostly safe to say that RPA vendors are not cloud ready yet. It seems they don’t have a proper plan to support Continuous Integration and Deployment also. Although you may achieve this today, it would prove to be a Herculean task.

Closing Remarks

RPA vendors must concentrate on building a platform that’s extendable, optionally customizable and can plugin and naturally play any custom built skills. Let the developers around the world build the skills. If they try to eliminate the developers from the equation, RPA will be a disaster and will bite the dust. Who knows what Artificial Intelligence would be fully capable of. Until AI proves that it’s feasible to eliminate coders, RPA should NOT assume it. As it’s today, RPA is an Orchestrator that can create symphonies by leveraging several individual skills that are part of or plugged into the platform or running externally somewhere on the Internet. Building the platform in such a manner could be the recipe for success. Openness alone can dictate the fate of RPA as a technology (or as a concept). The more open you are to the world, the more open the world is to you.

PS: Please leave your comments and share your views. Thank you.

Entering listen mode … Krishna Pisupat

Robotic Process Automation – How robotic it is and how novel the technology is? Are “bots” really software robots? What RPA means to Business personnel, Technical people and Corporations. Where does it meet Artificial Intelligence today? How well would it be married with Artificial Intelligence tomorrow? If you are on Business side or Technical side, how exposed are you to RPA disruption and how can you be prepared for it and leverage it?

There has been a lot of buzz around Robotic Process Automation (RPA) off late. If you are new to this concept and technology, you would wonder what it is. From the name you may tend to think it’s something to do with Robotics. From all the buzz around Artificial Intelligence in conjunction to RPA, you might even think it’s related to Artificial Intelligence. Let’s see what is myth and what is fact.

What is RPA?

To understand what RPA is one needs to understand what a process is. Any sequence of steps that are performed to fulfill a business need is a process. Generally a process includes the real recipe of the process – steps to achieve what is really intended to achieve, a few best practices, a few regulatory and compliance stuff, creating audit trail etc. For easier understanding let’s take something more concrete.

You are applying for a credit card with a credit card provider. You fill the application either online or through a paper application. In either case, an associate of credit card provider has to validate all the furnished information for completeness and correctness – whether you provided your first name, last name, address, annual income and finally whether you signed the form or not. Then run a bunch of verifications and validations such as background and credit checks. Finally enter all these details in a system and run a risk model that determines your eligibility and credit limit. The whole sequence of steps is a business process.

In a non-RPA world, all or some of these steps are performed by a human. Of course, in a digital world, most or all of these tasks can be done programmatically. You can build a web application so that customers can apply online and a business process can be built with one of those well known BPM (Business Process Management) systems. If all the process can be automated by a BPM system, what’s the need and role of an RPA system?

That’s where things get interesting. Let’s jump to the real world. Unless we are talking about a new organization that’s completely built ground up for this use case, the above automation is often an integration project among several in-house and third party systems. For example, credit check is often provided by a third party application which will be invoked by the credit card provider. Whenever we talk about Integration, there is a lot of complexity, confusion and cost involved. Integration generally requires both the service provider and consumer to agree upon a few protocols and standards. On top of that, there are software development costs for both the ends. Also, not all applications are integratabtle as a few are legacy or extremely complex systems – a few applications won’t even have an API which makes it impossible to integrate with them. Even BPM cannot help in these situations. In some cases even if you can leverage BPM, these projects are so costly that there won’t be any ROI (positive cashflow) after factoring in the software license, development and maintenance costs.

With RPA, most of these issues are solved in an economical way. RPA is NOT a single technology. Instead it’s a collection of tools a few of which have been in use for more than a decade. A few tools that are integrated in RPA platform are

• Record and Play tool – Records what a human performs and repeats it any number of times. Of course you can customize it so that each run can be performed with a different data set. If a human copies a row of excel spreadsheet and pastes in a form on a web page, this tool can simply repeat the same task – it opens the excel, highlight the text, copy it, open browser, log on to the application, navigate to the intended page and paste the content in the correct field of the form
• Web Scraping tool – Reads a web page and extract content out of HTML
• Other content extraction tools – Extract the content from spreadsheets, PDFs and images using OCR (Optical Character Recognition) techniques etc.
• Rule Engine – Allows users to write rules which dictate the conditions to all the above tasks when to run and when not to run. Validations and verifications can also be performed by a rule engine.
• Orchestrator – Helps to build the sequence and flow of tasks to determine execution order

If you are familiar with any of the automation testing tools, record and play and site scraping tools must be well known to you. Using these tools, one can mimic a human being with out doing any integration among disparate applications. As a result, any application – whether it has an API layer or not, it’s developed using a new technology or not, you can integrate it with an RPA application. In fact, even the application provider would be unable to identify whether a human is performing these tasks or a bot is performing them – of course a few sites build captcha and similar techs to avoid bots.

For BPM professionals, rules engine and orchestrators are inevitable tools. These tools help to provide order and conditionality to an RPA bot.

What RPA is NOT?

As it’s today, RPA does NOT leverage much of Artificial Intelligence or Machine Learning. Most of the out-of-the-box RPA products do NOT have this integration yet. If you ask me whether RPA is any Robotic, my answer would be a big NO. Of course, what you build with RPA could be eligible to be called a “bot”. But beyond semantic meaning, it has nothing to do with Robotics.

As it’s today, most of the vendors’ bots are run independently as isolated processes. Probably at some time in future, they have to be invocable from other software products so that they can be launched on-demand and as part of a larger business process that involves non-RPA systems.

What it means to you?

I hope, by now, you got a conceptual view of what RPA is and what it is capable of at a very high level.

Business Personnel – If you are a business personnel who performs any repetitive tasks which are mundane and require a little or no business knowledge, it’s possible you may be replaced by a bot as of today.

If your job needs simple to medium level of business knowledge that can be encapsulated into some kind of structure and logic, you might be taken over by RPA as well. RPA technology as it’s today can perform your role very well.

If you are a Subject Matter Expert in a business area and it takes a lot of learning to reach where you are, then you are safe for now – at least until RPA integration with Artificial Intelligence is improved.

Technical Personnel – If you are a BPM professional, you may need to learn RPA soon. I believe, this is the skill that could be at risk because of RPA to start with. RPA is a natural evolution for you.

If you are a software programmer, you should be worried too. RPA cannot replace all software projects. However, some of the projects that would have been developed in traditional ways would now be developed using RPA. It means less demand for Software Programmers.

What’s the bright side?

Business Personnel – RPA truly empowers business personnel to take the control of automation. Your Subject Matter Expertise could still be appreciated. You don’t have to rely on Technical personnel as much as you used to. Significant portion of RPA implementation requires a little or no technical knowledge. It means, if you are willing to learn RPA, it would be actually a boon to you. Just to clarify, you don’t have to learn writing software code but you can implement at least half of automation yourself.

Technical Personnel – RPA is nothing challenging given your technical background. Learn it today. You can still share half the automation pie. Not all of the automation is programming free. You still need to implement some complex logic through scripts and programming. On top of it, maintaining, monitoring of RPA environment would still require technical expertise. Join all of this with Analytics and insights – you see a bright spot on the other side of the tunnel.

Leadership – There is a lot of cost cutting waiting for you to grab. Jump into RPA and adopt it. It could mean a very fat bonus for you at the year end.

Closing Remarks

I don’t put RPA and Artificial Intelligence in the same bucket as of today – they are two different worlds. On the contrary, RPA has nothing intelligent in it. However, it’s only a matter of time before they complement each other.

Nevertheless, RPA is going to be a disruptor if it’s not already. There is still an early mover advantage on the table if you are ready to adopt it.

PS: I welcome all constructive comments. Please feel free to leave them here. Thank you.