Comment by wkrause

There are two primary types of RPA, attended and unattended. Unattended automations make for good candidates for replacement with systems that have proper API's. The issue I've seen is that most of the underlying back office systems have a weird division of business logic between the view layer, the server and the database such that no one wants to risk trying to detangle the systems. In theory RPA can act as a bridging technology that lets you first create something closer to a proper API. Then if new apps built on top of those API's provide value, it becomes easier to justify a re-write of the underlying systems. So it kind of helps build the political will in larger organizations by making the value of the future state of sunsetting the legacy systems more real to those outside of the tech org.

Attended automations, when done right, function as a window orchestration tool for multivendor workflows where the end user needs to be in the loop, maybe for compliance reasons, or because they need to use some professional judgement like underwriters. Even when platforms have solid API's, they rarely have deep linking with enough sophistication to take the user to the proper screen for a multi-application flow. In a perfect world you'd map out relevant workflows, and write some simple glue apps that are built on top of multiple APIs, which is what Power apps is kind of trying to do. The reality is that SME's can be really attached to certain systems and ways of doing things, that the cost of retraining on a new flow is often not politically viable. So it becomes easier to augment the workflows, pulling up SharePoint docs when certain conditions are met, partially filling out forms in some webapps, etc... than search for a global maximum.

I guess in short, I think there are pragmatic ways to use RPA without resigning yourself to never doing the necessary work of rearchitecting the systems that made RPA necessary in the first place.