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.