* 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.
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)
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?
> 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.
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.