100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API).

The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution.

I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.

Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them.

Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions".

I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.

You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.

The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT.

IT promise to business: "You can use RPA if we tell you we can't build a thing in time."

Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."

And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical).

This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}.

In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data.

(It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)

>IT promise to business: "You can use RPA if we tell you we can't build a thing in time." > >Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."

This is the _whole_ life-cycle of a correct RPA implementation. The only successful RPA automation is the one that gets turned off because it has been solved for in the enterprise application level.

In my experience, the lifecycle is more like:

* Person in the business area implements RPA. Business area is happy.

* Person who implemented RPA moves on to greener pastures.

* RPA breaks, business area calls IT.

* IT is horrified at the unsupportable mess that's just been dropped in their laps.

1000% this.

I’ve seen it happen with excel, access sql-server; and RPA. Some some Frankenstein’s monster is cobbled together to solve a problem whose best solution would be “stop producing the report that nobody looks at” only to have it slowly decay out of orbit.

The other major flaw with RPA is non-engineering LOB employees (in my experience) are incredibly myopic and implement solutions to get shit done now without thought about future consequences of their decisions. They try to replicate the 800 steps they take to make something work instead of asking “more steps adds opportunity for failure; what is the minimum I need to do to reach goal”.

/soapbox (Sorry)

That's why the documentation prod gatekeeping is critical to long term company health.

You're not going to stop them doing things -- because there's never "enough" IT / they always have Excel.

So what's the next least bad?

IMHO, give them something flexible enough (RPA) that they don't have to go outside of the box + require they leave a documentation trail of what / why they built. (Oh! And teach them about SLAs and SRE best practices!)

Then come down like a ton of bricks if they don't follow the latter. Carrot & stick.

Cheaper pressure release valves (RPA), not expensively overengineered containers (hiring more engineers).

---

Ironically, the hardest conversation at (insert F500 I designed an RPA practice for)?

"Business users shouldn't be able to use IT change control tools!"

Wait... isn't this exactly what we're always griping they don't do?

> "Business users shouldn't be able to use IT change control tools!"

> Wait... isn't this exactly what we're always griping they don't do?

This is something I hate. In IT, we use change control processes - change requests which have to get approved, discussed at the change advisory board, etc.

There are a lot of questions to answer before something goes into Production: Was it tested internally? Did the business area test it and sign off on the change? Is there evidence of said testing? Was code review completed? Is there a backout plan?

I've never seen the same rigour applied to configuration or processes that are managed by the business area, even though their configuration can do quite a bit of damage. Change the inactive customer purge time from 2 years to 2 days? Oops, virtually all of the customers have been purged.

Sometimes the solution is also "Get IT to fix the thing that you're working around"

There was a delivered process to do a particular job, but it didn't work. Nobody thought to tell IT that it didn't work, instead they built a Ruby+Selenium script and ran it on a spare computer. Which worked great until it didn't.

How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.

"Integrate at the UI layer" is a can of worms.

In simple cases, it's clicking a button.

In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together.

Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text boxes, containing 12 rows, which moves / updates the contents of each box as the user scrolls.

I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".

My comment wasn't about fragility, it was about how compatibility was long tail.

And long tail, accreted one weird customer at a time things are definitely a moat.

Most of them look for window events. I've not seen an RPA tool that actually reads the screen like a human, even though that's how you're thinking about it.

The bit players simply map Active Accessibility / whatever MS calls it now (Windows Automation Framework?).

The more serious players shadow Windows events.

The real stuff does process injection and directly shadow copies / modifies in-memory data structures.

That's not how I'm thinking about it.