While attending the CamundaCon conference last week, the intersection of RPA and process was explored across several conversations. An interesting development to see RPA so prominently featured in a conference sponsored by a process engine company - and at the same time, how can you not talk about the fastest-growing segment of enterprise software and how it might impact process design?? What happens when a Bot and a Process walk into a virtual conference together?
At BP3, we help you find a faster way to get to your specific business outcomes, sometimes which means starting with RPA and other times with process engine technologies to do so.. It feels appropriate to share some perspective on the conundrum of RPA vs. Process or RPA and Process. The short version: both technologies have great potential to create value for you!? Each technology is most appropriate for particular starting points - and how you leverage them together also depends on how you start.
Are RPA Vendors Converging on Process?
Scheppler kicked off this discussion during the conference with the following comment:
"I have been observing RPA providers for just over two years. They are now much more than just front-end integrators; they support state machines, process metrics and much more. The difference to Workflow Engines is getting smaller with every month. The main difference for me is performance and of course BPMN. Do you guys share this observation?"
And it is true. If you look at the recent product plan announcements from the leading RPA vendors, they are encroaching on the space of traditional business process engine vendors. Process Suite vendors are, in turn, acquiring RPA capabilities either through partnership or acquisition. However, it isn't quite as clean an analysis as this.
For process suite vendors, adding automation capabilities is, conceptually, straightforward. If I put myself in their shoes: I have all the context in my processes, but sometimes there are integrations or interfaces with other systems that don't have an API, or rely on human intervention, for which I could use RPA bots - almost like a person with an incredibly narrow job description - to make that integration work. In effect, the reason process vendors have a hard time making RPA bots a great part of their portfolio, is that they're only thinking about bots and robotic automation in the context of their processes. In other words, the bots serve the process, they're not a first-class citizen in their product plans and mental models. You know this is true when you hear process vendors refer to RPA as "technical debt" or "band-aids". On the other hand, people are first-class citizens in process design considerations - with roles, human activities, and UX getting a lot of attention from process vendors.
For RPA vendors, robotic automation is the job, and the adding process is a bit of an afterthought. If I put myself in the shoes of an RPA vendor, I just have a very different perspective on solving business problems, because of where I'm starting from. With RPA, I'm starting with specific human activity and looking to automate it - and then find lots more specific human activities to automate.? That is the first-class problem I'm focused on. My theory of the case is if I can just democratize this kind of automation by augmenting human workflows and speed, then in a bottom-up fashion, I can create a lot of efficiencies and values for my business.
So, as an RPA vendor, my interest in the process isn't to have a top-down design in a centralized planning group. Most of those designs will never get to the very edge cases of automating specific activities... It's too many levels down from the high-level abstraction of an Order to Cash process, for example.? RPA bots look like they're following processes - conceptually they are - 15-20 steps to do something a human would do with a little bit of training and on-the-fly thinking.
But RPA vendors are encroaching on the process space. They're looking at all these bots and automation and thinking it would increase adoption: if it is easier to re-use; if it is easier to connect automation; if it is easier to discover new opportunities to automate activities; if it is easier for humans to define them; if it is easier to read documents like a human; if it is easier to read from and write to forms.
Having said that, RPA vendors are going to have to adopt some new DNA around user experiences to really embrace the full scope of the process. RPA vendors refer to places where people are involved in the process as a "human-in-the-loop", where the automation waits on an action by a person before proceeding. The patterns around these implementations are well-understood in process engine circles, but it isn't clear how the RPA vendors will store state and scale while waiting for human responses.
Conceptually, a process design starts at a higher level, end-to-end - and only after that is designed does that design dive deeper to the level of activities. And an RPA design starts with a very narrow human activity and then looks at other activities at that level, and only later looks upward. These are two sides of the same coin. Process engines automate orchestration and integration, and RPA software automates human activities via emulation. Someone commented in CamundaCon:
"Having worked with Camunda and UiPath, I would much rather write business processes in Camunda. The Camunda engine provides much better modeling tools, a built-in persistence of state (which is not provided by UiPath), and better observability of currently running processes and incidents."
Of course, there is no question Camunda is better from a process purist point of view.? RPA's point of entry is so different - a task that needs automating, that is more difficult to wrestle under control with traditional code and API approach - thus human emulation. Camunda gives you the advantage when you're really more concerned about the whole process, and automating parts of the human activities in those processes is less important. Of course, you can be worried about both perspectives at the same time.
Is RPA a Transitional Technology?
"Regarding the use of RPA, I am interested in hearing from those that view it as a transitional technology versus a technology to be used intentionally in current and future projects."
I think there were, not surprisingly, many who agreed with this sentiment.? The view is: I have something I need to do that I just don't have an API for, and therefore I'll use RPA - until I eliminate the need for it by replacing it with an API or redesigning the process.
This is a commonly held view by process-first folks over the last 3-4 years.? And I can't say that it is wrong, but in the last 3-4 years, RPA has gone from barely on the radar, to having several RPA vendors worth several Billion dollars each (considerably more than the pure-play process vendors). Are RPA bots PC's and process engines the mainframes of this particular software market? The inelegant upstarts who solve workaday problems, rather than having ideal diagrams of ideally designed processes coordinating the enterprise? I'm not sure that process vendors aren't much more agile than the mainframes of yore (after all, we *are* talking software here), but the analogy is an interesting thought experiment.
Is RPA the PC of the process era, or is RPA in fact a transient technology - something meant to get you over a bump in the road that will later be smoothed out?
It could be both.
I think it is a mistake to think that the only role for a bot is as part of a process in Camunda or some other process engine - you'll miss too many opportunities for ROI. I've previously written about RPA's new rules, and what we've learned about RPA, and 8 reasons to use RPA - and it is clear there are many cases to emulate human interactions with systems that don't cleanly fit the band-aid metaphor, nor do they require a top-down process point of view to start with. Don't let those opportunities be ignored just because they don't fit neatly into a top-down process design.
RPA: Is it a Waste of Computational Resources?
Another interesting point in the discussion of RPA:
"how much more computation power [with RPA] do you spend in rendering, network traffic, paring, running the bot, to achieve the same amount of work compared to APIs?"
What a great question! On the one hand, yes it runs a lot of extra cycles to solve the problem vs. APIs. Of course, the simple answer is to flip that around - rather than comparing RPA resources to fully automated APIs, compare the use of resources by RPA to the cost and resources required for a human to do the same work. RPA clearly sits somewhere in the middle between API-driven solutions and Human-driven solutions - your hybrid gas-electric rather than full-electric alternative, if you will.
Could RPA be "Just Another API"?
Of course. RPA vendors expose APIs for their bots and automation, and you can drive their execution and schedules via APIs. The style of calls on those APIs usually requires a callback routine, in order to avoid time-out issues, but otherwise, there's no reason why we can't put RPA (or even human) behaviors behind an API.
Is the Ideal Use Case to Have a Process Engine Coordinating and Monitoring All of the RPA Bots and Tasks?
In theory, sure. The problem is that this misunderstands why people use RPA. In the solutions you build from the start with both process and RPA technologies, you'll find more reasons to design like this. But there are many use cases that will leverage one tech or the other because the problems are a natural fit for RPA software or a natural fit for process orchestration.
Should RPA and Process Engines be Bundled? Or Should You Pick and Choose What You Feel are Best for Your Needs?
If you haven't previously used a process engine or an RPA suite, then a bundled approach makes sense to consider, if only to simplify your licensing and support.? However, odds are you have a process engine - or an RPA suite - if not more than one of each.? If so, then it may prove more expedient to choose the best the market has to offer in each category, based on your needs.
I don't think there is any magic to this thought process. If your RPA suite includes some process capabilities, you may want to use them.? But if your goal is to really have a top-down process-oriented view of your enterprise, you'll want to use software specific to the task. And likewise for task automation capabilities in RPA.