At CamundaCon there were in-depth discussions about the role of process engines and RPA software, as well as how to orchestrate all the RPA bots people are building.
Since then, an article on Deutsche Telekom Service (DT Service) has revealed a deeper look into one company's use of both process and RPA. The article is partly a look at DT Services' use of both technologies, and partly a recap of the very good panel discussion in which they took part. Right off the bat, there's a bit of music to the process purists' ears:
Asked what he would have done differently if he could have his RPA time over again, Einacker was emphatic ? I would have separated the process orchestration from the bot execution layer right from the beginning?, he said. That would have been much more beneficial for us in terms of maintenance costs?, he added.
I've had a client describe it to me this way: that they use a process engine to orchestrate all the work in their defined processes - human or otherwise - and that they think of the bots as just like humans but with extremely narrow job definitions.
I've often commented that we've observed how important context is to doing RPA well, and here is some further ammunition to that argument:
DT Services [RPA] visibility was poor as they could only monitor single bots and not the end-to-end business processes?, said Freund. ? The overarching Camunda layer work can implement workflow and decision logic?, he added.
Many argue that RPA is technical debt - or instant technical debt - but of course really it is both - depending on how it is used (music to RPA aficionados' ears):
To illustrate the point, Einacker flagged a use-case within fixed-line repair. Historically, after carrying out repair work, field engineers would make an inbound call to a colleague in order to check line performance. ? One of the biggest pain points in the process was calls held up in queue. How did we solve this? With RPA. To solve this with a proper technical core IT solution would have taken perhaps two more years?, said Einacker.
It's a great article and I recommend reading the whole thing.? What I would focus on while reading it, are Einacker's specific use cases and insights - both the process engine and the RPA bot have a role to play - in some cases the bot is temporary, but that doesn't mean that it isn't relieving technical debt, or deferring a large technical investment with little value.
Moreover, the article really makes clear how important orchestration is to successful RPA programs that want to achieve the next level of efficiencies!
