[michaelmrose]

Presumably your engineers didn't want to move from world a where they understand why things break to world b where any change even to a landing page could cause a cascade of failures due to automation that depends on that page.

A world where such failures causing production to fail become more likely because its challenging to predict ahead of time who depends on what and it what way.

Where they presumably have to then debug the mess.

Your engineers were right and unfortunately you are probably wrong about dumb ideas not selling.

[eksemplar]

Predicting time and allocating resources is my headache, and while RPA will make that worse, it also supports our primary function in a way that gives our more possibilities than we’ve had in years.

If we can save nurses for 10.000 administrative hours a yearwith RPA, then we’ll absolutely do it, even if it comes at the cost of having more work in operations. I mean, why wouldn’t we? Supporting the business end is our sole purpose of existence.

It’s not that bad though. We mainly use it as a last resort, either as something temporary while we wait for an API or on systems that will never have an API. A lot of these systems are old, one of our mainframe interfaces haven’t changed in 16 years.

On top of that, patch notifications in the public sector are often written solely for end users. This means that it’s actually easier to predict a button changing in an interface than an API breaking.

I’ve seen REST interfaces change, and break, without warning because the REST bit was really just slapped on there by sales.

Our first RPA poc saves us around 9.000 hours a year. It helped us get our case working up to a point where we’re within the legal deadlines (something we’ve never been before) and due to the lower pressure in the department we’ve managed to turn employee satisfaction from a 4/7 to a 5.6/7 and reducing sick leave from 15% to 8.

My department had to hire an extra engineer because if it and the business end had to allocate 1/4 of a yearly position to support the process. The business case is still green financially.

My engineers have never been more wrong. Even if the tech sucks, but that’s still my headache. Because I fully realize I can’t have a CS candidate do drag-and-drop programming full time and keep them happy.